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1.0  Introduction 

This  document  contains  information  useful  for 
assessing  the  applicability,  complexity,  and 
feasibility  of  implementing  the  RASSP 
methodology.  The  Study  Phase  investigated 
eleven  topics.  Each  investigation  consisted  of  1) 
a  feasibility  of  the  proposed  RASSP 
methodology,  2)  a  compendium  of  related  work, 
3)  a  discussion  of  any  perceived  or  known 
problems,  and  4)  a  discussion  of  possible 
solutions  to  problems. 

The  report  is  organized  to  provide  information  to 
program  managers  in  support  of  their  efforts  to 


manage  the  risks  inherent  in  the  Implementation 
Phase  of  the  RASSP  program.  This  report  has 
three  major  sections.  Sections  1  and  2  provide 
introductory  and  summary  information.  Section 
3  provides  detailed  information  on  eleven 
separate  categories  as  defined  in  the  Statement  of 
Work  in  solicitation  RFP  MDA  972-92-R-(X)17. 
These  eleven  sub-sections  make  up  a 
compendium  of  study  phase  repons  that  together 
form  a  comprehensive  reference  useful  for 
gaining  insight  into  the  complexities  and 
feasibility  of  developing  application  specific 
signal  processors  that  meet  MODEL  YEAR  cost, 
schedule,  and  upgrade  objectives. 
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2.0  Executive  Summary 

2.0.1  Study-Task  Objectives 

The  objective  was  to  study  eleven  critical  areas 
and  document  major  issues,  potential  problems, 
possible  solutions,  current  state-of-the-art, 
feasibility  of  RASSP  objectives,  and  related 
work.  The  eleven  areas  are: 

•  Design  and  Design-System  Requirements 

•  Interoperability  Considerations 

•  Design/Manufacturing  Interface 
Considerations 

•  Manufacturing  Considerations 

•  Testing  Procedures 

•  Equipment  Requirements 

•  Facility  Requirements 

•  Database  Requirements 

•  Teaming  Arrangements 

•  Establishment  of  Military  Sources 

•  Target  Systems 

2.0.2  Technical  Problems 

The  major  technical  issues  are  concerned  with  the 
Design  System,  Standards,  industry  integration 
and  manufacturing  resource  links.  Action  items 
were  accepted  at  the  Final  Program  Review  to 
expand  on  these  issues.  Three  action  items  are 
addressed  here  as  a  summary. 

ACTION  I.TEM.J 

Subjects:  CFI,  Block  Releases, 
Expediting 

The  Final  Report  should  contain  a  discussion  of 
the  present  CFI  plan,  a  suggested  approach  for 
expediting  the  standards  development,  a 
suggested  approach  for  expediting  its 
promulgation  by  MENTOR,  CADENCE,  DEC, 
and  COMPASS,  and  how  the  improved  plan 
might  fit  in  with  the  Raytheon  concept  of  block 
releases. 

During  the  Study  Phase,  CFI  Inc.  and  various 
CAD  framework  vendors  were  approached 


concerning  this  issue.  CFI  has  provided  us  with 
their  proposal  and  funding  requirements  profile. 
The  industry  interaction  and  nuances  are  complex 
and  will  find  many  problems  to  overcome  in  the 
course  of  obtaining  full  CFI  and  RASSP  goals. 
Our  approach  is  one  of  both  “push”  and  “pull." 
CFI  Inc.  needs  support  and  perhaps  expansion  of 
their  projects.  The  industry  needs  a  means  of 
resolving  conflict,  but  what  is  more  important  is 
ensuring  that  what  evolves  is  fully  marketable. 
The  RASSP  funding  of  CAE  vendors  to  provide 
the  various  elements  of  Block  one.  Block  two, 
and  Block  three  “RASSP  Design  System” 
provides  the  “pull."  It  also  establishes  a 
mechanism,  along  with  workshops,  symposia 
and  newsletter,  to  sell  the  capabilities  to  industry. 
This  is  accomplished  not  only  through 
demonstrations,  but  through  making  the  design 
system  available  to  industry  evaluators  for  hands 
on  use. 

CFI  (CAD  Framework  Initiative)  is  an 
international  cooperative  effort  within  the 
electronics  industry.  (TFI  was  formed  in  1988  as 
a  non-profit  organization  with  the  following 
mission:  “Define  interface  standards  that 
facilitate  the  integration  of  design  automation 
tools  for  the  benefit  of  end  users  and  vendors 
worldwide.” 

Today’s  design  engineers  are  generally  not 
satisfied  with  the  performance  and  functionality 
of  their  hardware  and  software  automation  tools. 
Because  no  single  vendor  offers  the  best  solution 
for  all  users’  design  problems,  users  often  piece 
together  their  own  set  of  solutions.  This  results 
in  wasted  design  time  spent  painfully  integrating 
tools  from  different  sources.  CFI  was  formed  to 
address  this  problem.  Among  its  members  are 
design  automation  vendors,  computer  and 
semiconductor  suppliers,  and  CAD  tool  end 
users,  as  well  as  government,  research  and 
academic  institutions.  CFI  believes  that  effective 
use  of  standard  frameworks  will  raise 
productivity  among  users  by  providing 
interchangeable  tools,  and  will  allow  vendors  to 
focus  on  tool  functionality  rather  than  reinventing 
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proprietary  interfaces. 

CFI  believes  that  a  framework  should  be  a 
layered  procedural  interface,  supponed  on 
multiple  platforms,  that  is  modular  and  easily 
extensible.  The  CFI  mission  is  synergistic  with 
other  industry  standards  efforts,  such  as  the 
Open  Software  Foundation  (OSF),  the  Electronic 
Data  Interchange  Format  (EDIF)  and  the 
government  funded  Engineering  Information 
System  (EIS)  program. 

Raytheon  Company  has  a  subscription 
membership  to  the  CAD  Framework  Initiative 
and  has  been  closely  tracking  the  activities  of 
CFI. 

Much  of  the  work  of  CFI  is  now  documented  in 
the  draft  specifications,  user  guides,  reference 
software  and  regression  tests.  CFI  refers  to  this 
collection  of  items  as  CFI  Pilot  Release  1.0.  It 
includes  the  following  draft  standards. 

•  Design  Representation  Electrical  connectivity 
Information  Model  and  Programming 
Interface. 

•  Inter-tool  Communication  Procedural 
Interface 

•  Inter-tool  Communication  Architecture 

•  Inter-tool  Communication  Base  Object  Model 
and  Interface 

•  Tool  Encapsulation  Specification 

•  Execution  Log  Format 

•  Base  Networking  Services  Guideline 

•  Base  System  Services  Guideline 

•  CFI  Users,  Goals  and  Objectives 

RASSP  Applicability 

The  above  standards  will  partially  address  many 
of  the  areas  required  for  RASSP  including 
Incremental  Changc/Analysis  Tool  Invocation 
and  Control  and  a  Standard  Extension  Language. 

CFI’s  RASSP  plan  defines  four  Integration 
Phases:  Phase  0-EDA  Systems  Integration, 
Phase  1-  Manufacturing  Integration,  Phase  2- 
CASE/Codesign  Integration,  and  Phase  3- 
Enterprise  Integration. 


What  CFI  brings  to  the  RASSP  program  is  a 
model  for  developing  framework  standards.  CFI 
has  been  successful  in  selecting  a  specific 
problem,  getting  large  end-user  companies 
experiencing  the  integration  problem  to 
participate,  and  getting  vendors  to  work  together 
to  solve  the  end  user's  problem  by  developing 
the  appropriate  standards.  CFI’s  RASSP 
funding  requests,  totaling  $4.1  million  over  4 
years,  covers  CFI’s  costs  of  coordinating  the 
framework  standards  development  effort.  It 
includes  the  cost  of  a  program  manager,  general 
support  to  the  vendors  and  end-users, 
development  of  specifications,  technology,  and 
regression  tests.  It  does  not  include  costs 
incurred  by  the  vendors  or  end-users  involved  in 
the  standards  development  effort.  However,  CFI 
has  been  successful  in  the  past  in  getting 
companies  to  volunteer  their  own  time  and  effort 
to  develop  the  standards. 

CFI’S  RASSP  Phase  0  And  CFI’S 
Release  2.0: 

CFT’s  release  2.0  should  complete  CFI’s  work  in 
the  EDA  area  including  specifications  for  a  Multi¬ 
simulator  Backplane  and  Library  Standards. 
Process  Management  and  Data  Management 
standards  are  just  beginning  to  be  addressed. 
CFI  admits  that  there  is  still  much  work  to  do  in 
these  areas,  specifically  regarding  namespace 
resolution,  and  that  without  additional  attention, 
standards  will  not  be  available  in  the  short  term. 
RASSP  program  influence  with  CFI  and  the 
contributing  CAD  vendors  can  shorten  this 
schedule. 

CFI’S  RASSP  Phase  1: 

The  RASSP  program  could  have  a  greater 
influence  in  the  Manufacturing  interfaces.  These 
programs  are  still  in  the  vision  stage  and  there 
exists  the  possibility  that  they  may  not  get  off  the 
ground  at  all  without  government  input. 
Raytheon’s  general  belief  is  that  manufacturing 
interfaces  would  be  developed  by  CFI  regardless 
of  the  involvement  of  the  RASSP  program  but 
would  not  be  at  a  pace  sufficient  to  ensure 
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RASSP  success. 

Cn’S  Phase  2  And  3: 

Standards  for  CASE/co-design  and  enterprise 
integration  play  a  major  role  for  RASSP.  This  is 
basically  a  “cottage  industry”  with  no 
standardization.  The  RASSP  program  would 
have  a  large  impact  in  this  technology  area. 
Without  RASSP  involvement,  there  is  a  chance 
these  areas  will  not  be  addressed  at  all.  Phase  2 
and  3  cannot  be  accomplished  within  the  RASSP 
program  time  frame.  RASSP  design  system  will 
provide  an  implementation  that  will  seed  further 
CFI  standard  development  in  these  areas. 

Approach 

Raytheon’s  suggested  approach  is  to  have  the 
DARPA  fund  a  number  of  resources  available  to 
all  the  RASSP  contractor  teams.  These  include 
CFI  and  NIST.  The  funding  level  for  CFI 
should  be  approximately  $1  million  over  the  four 
years.  CFI  will  provide  general  suppon  and 
consulting.  This  funding  will  also  help  CFI  in 
development  of  specifications,  technology,  and 
regression  tests.  The  contractor  team  should 
have,  as  team  members,  at  least  two  framework 
companies  and  a  group  of  CAD/CAM/CASE 
vendors.  The  two  framework  companies  will 
ensure  that  the  design  system  is  not  vendor 
specific.  The  CAD/CAM/CASE  vendors  will 
provide  the  needed  design  functions  within  the 
frameworks.  The  contractor  team  will  ensure 
that  the  developed  design  system  will  meet 
RASSP  goals  and  conforms  to  CFI  standards. 
Within  this  teaming  and  support  structure, 
RASSP  and  framework  houses  will  be 
coordinating  releases  of  the  RASSP  design 
system.  The  main  reason  for  this  approach  is  to 
reduce  the  risk  of  CAD/CAM/CASE  vendors  not 
participating  and  conforming  with  standards. 

This  approach  will  also  expedite  the  standards 
development  because  real  application 
implementation  and  demonstration  will  accelerate 
the  development  process. 

With  regard  to  CFI  and  the  Raytheon  concept  of 


block  releases;  our  block  releases  will  conform 
to  whatever  is  available  at  the  time. 

•  At  block  release  one,  not  all  EDA  Systems 
integration  standards  will  be  ready.  In  block 
one  release,  the  contractor  will  bring  the 
design  system  (with  its  tool  sets)  to  the  CFI 
release  1. 

•  In  block  two  release,  the  design  system 
should  conform  with  CFI  release  2.  There 
should  also  be  some  implementation  of 
manufacturing  integration  that  will  be 
coordinated  with  CTI. 

•  In  block  three  release,  the  design  system  will 
consist  of  upgrade  of  manufacturing 
integration  to  CFI’s  manufacturing 
integration  standard.  Block  three  release  will 
also  start  the  implementation  of  CASE/co- 
design  integration.  This  implementation  will 
contribute  to  CFI’s  CASE/co-design 
integration. 

In  summary,  much  of  the  standards  related  work 
required  for  the  RASSP  program  will  occur 
regardless  of  the  RASSP  program’s  involvement 
in  CFI.  However,  the  delivery  dates  and  the 
sample  implementation  will  probably  not  match 
those  required  by  this  program.  CFI’s  track 
record  in  the  development  of  standards  is  good 
and  there  is  no  reason  to  believe  that,  with  proper 
funding  and  participation,  the  additional 
standards  required  for  RASSP  would  not  be 
accomplished  in  a  timely  and  complete  manner. 
Raytheon’s  teaming  approach  will  facilitate 
working  with  CFI.  Raytheon’s  design  system 
block  release  will  conform  with  CFI  standards 
available  at  the  time  and  will  also  help  CFI’s 
framework  development  process. 

ACTION  JTEM-2 

Subject:  RASSP  CAE  Investment 
Strategy 

Indicate  which  design  system  elements  are 
critically  important  to  RASSP  and  have  probable 
development  time  lines  that  are  compatible  with 
RASSP’s  four  year  plan.  luentify  which  current 
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industry  efforts  are  going  in  the  right  direction. 

During  the  RASSP  Study  Phase,  the  Raytheon 
team  researched  applicable  CAE  tools  and 
methods  (commercially  available,  advanced 
research,  and  applicable  DoD  initiatives).  These 


are  presented  in  section  3.1  of  the  study  phase 
final  report.  Included  with  the  list  of  tools  is  an 
overview  of  the  functionality  and  input  and 
output  mechanisms.  Some  of  the  tools  are 
compatible  with  the  use  of  standards  (for  input 
modeling  and  use  of  libraries)  within  the  current 


Tools 

Use  of 
Modeling 
Standards 
(input  & 
Output) 

Integration 

with 

Standard 

Libraries 

Ease  of 
Use 

Open 

Architecture 

Link  to  Other 
CAE  Tools 

Scientific  and 
Engineering 

Software  (SES) 
Workbench 

Yes 

Yes 

Yes 

Link  to  software 
through  pictures 

JRS’s  IDAS 

Yes 

Link  to  Synopsys’ 
Design  Architect 

Synopsys'  Design 
Architect 

Yes 

Yes 

Yes 

Link  to  several  target 
technology  foundries 
and  popular  digital 
schematic  capture 
tools 

Mentor  Graphics’ 
System  Design 

Station 

Yes 

Yes 

Link  to  University  of 
Virginia  U/I 
Performance  Models 

Redwood  Design 
Automation  Tools 

Yes 

Yes 

Unreleased 

information 

i-Logix's  Statemate, 
Express- VHDL 

Yes 

Link  to  major  logic 
synthesis  tools 

University  of 
Virginia’s  U/I 

VHDL  Performance 
Models 

Yes 

Yes 

Yes 

Link  from  Mentor’s 
Block  Diagram 
capability 

IDE’s  Software 
Through  Pictures 

Yes 

Yes 

Link  to  SES 
Workbench 

Cadre’s  Teamwork 

’les 

Yes 

Link  to  Statemate 
and  ADAS 

Mentor’s  Falcon 
Framework 

Yes 

Yes 

Yes 

Yes 

C^  snee’s 

Framework 

Yes 

Yes 

Yes 

Yes 

1 


TABLE  2.0-1  SET  OF  SYSTEM  ENGINEERING  CAE  TOOLS 
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tools.  To  realize  RASSP  goals,  the  block  one 
RASSP  Design  System  will  take  advantage  of 
existing  tools  and  concepts  that  make  integration 
easier.  Early  pitx>f-of-principle  can  be  completed 
within  the  first  year  of  the  RASSP  program.  The 
following  are  important  criteria  that  are  followed 
when  choosing  CAE  tools  to  integrate  into  this 
first  design  system. 

•  Functionality 

•  Use  of  modeling  standards  (VHDL,  Ada, 
Verilog,  etc.)  for  input  and  output 

mechanisms 

•  Integration  of  CAE  tool  with  standard 
libraries  for  COTS  parts 

•  Ease  of  Use 

•  Open  architecture 

•  Link  to  other  CAE  tools 

A  particularly  strong  effort  will  be  made  to 
incorporate  system  engineering  tools.  Table  2.0- 
1  highlights  the  criteria  and  gives  a  set  of  system 
engineering  tools  that  are  moving  in  the  direction 
necessary  for  RASSP  goals.  The  functionality 
for  each  of  these  tools  is  available  in  section  3.1 
of  the  Final  Report.  Table  2.0-1  does  not  go  into 
detail  for  software,  hardware,  and  physical 
design  phases  of  the  system  design  life  cycle. 
Tools  for  software,  hardware,  and  physical 
design  phases  are  well  established  -  iniegrated  to 
a  large  extent  —  and  take  advantage  of  current 
modeling  standards  and  libraries. 

These  tools  are  currently  conforming  to  one  or 
more  of  the  criteria  described  above  and  therefore 
can  be  integrated  successfully  into  the  block  one 
RASSP  Design  System  within  the  first  year  of 
the  program.  However,  in  order  to  meet  long¬ 
term  RASSP  goals,  several  other  design  system 
elements  are  important.  A  list  of  those  design 
system  elements  follows  along  with  their 
expectations. 

Tools  with  the  following  functionality  are 
necessary  for  RASSP  program  and  should  be 
researched  and  developed  under  the  RASSP 


implementation  phase. 

•  Hardware/software  co-design  tools 

•  System  and  subsystem  functional 
partitioning/high-level  synthesis  tools 

•  System-level  manufacturing  advisor 

•  System-level  logistics  advisor 

•  System-level  packaging  compiler 

Database  Technology 

The  type  of  database  technology  required  for 
RASSP  model  year  design  system  makes 
demands  on  data  integration  rather  than 
traditional  database  technology.  The  fact  that 
data  is  stored  in  relational,  object-oriented  or 
system  file  is  less  important  than  the  fact  that 
these  data  e.itities,  however  represented,  must  be 
integrated. 

Many  activities  in  information  integration  are 
aggressively  being  pursued  on  an  academic  and 
practical  level.  Research  initiatives  in  this  area, 
sponsored  by  DoD,  have  been  ongoing  since  the 
1970’s  with  the  Air  Force  Information 
Integration  Support  System  (I2S2)  program,  and 
the  recent  XEROX  Design  Research  Center’s 
DICE  contract  for  in  its  explicit  support  for 
concurrent  engineering,  which  is  a  fundamental 
requirement  of  the  RASSP  design  system. 
However,  a  prototype  from  the  XEROX  activity 
in  the  meta  data  management  area  will  not  be 
available  until  1993  for  review.  Until  then,  it 
would  be  recommended  that  this  activity  be 
closely  followed.  Industry  activities  are  also 
prominent,  such  as  the  CALS  Data  Dictionary 
Task  Force.  Further,  Raytheon’s  internal 
investigation  of  integration  technologies  for  its 
implementation  of  the  Raytheon  Integrated 
Technical  Information  Service  (RITIS)  has 
reviewed  several  commercial  products  for 
implementation  of  the  data  dictionary  service. 
These  products  include  integration  technologies 
from  HyperDesk,  GRC,  DEC,  Information 
Builders,  Control  Data  Corp.,  Etc.  The  most 
promising  thus  far  has  been  the  Distributed 
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Object  Management  System,  from  HyperDesk, 
which  is  OMG  compliant.  It  would  be 
recommended  for  further  investigation  for  data 
model  implementation. 

For  Block  one  RASSP  design  system,  the 
current  Raytheon  RTTIS  plan  would  be  followed. 

CFI  PROGRAM 

It  is  anticipated  that  EDA  and  Manufacmring 
Integration  will  be  completed  within  the  RASSP 
program  time  frame.  The  RASSP  program 
should  provide  direct  funding  to  CFI  for  any 
additional  integration  strategies  such  as 
CASE/co-design  Ir  .egration  and  Enterprise 
Integration.  Additionally,  the  RASSP 
implementation  team  should  provide  input  to  the 
CFI  standards  efforts  through  its  CAD  team 
members. 

DL,  AHDL,  VHDL  Programs 

The  RASSP  program  should  provide  input  to  and 
a  strong  presence  within  the  standards  bodies  to 
ensure  success.  The  definition  of  AHDL  is 
slower  in  proceeding  but  will  be  defined  within 
the  RASSP  program  time  frame.  The  MHDL 
program,  under  Intermetrics,  is  still  in  its  early 
stages.  RASSP  emphasis  is  on  VHDL  and  its 
expanded  application  in  supporting  CALS,  PAP- 
E,  Fligh  Level  Co-design,  etc. 

Generic  System  Description  Language 

There  exists  the  need  to  develop  a  standard 
representation  for  system  models  that  can  be  used 
prior  to  partitioning  system  requirements  into 
subsystems  requirements  and  then  those 
subsystems  into  their  digital,  analog,  microwave, 
and  software  requirements.  Currently,  there  are 
no  standards  or  industry  organizations 
addressing  this  issue.  RASSP  can  monitor  and 
provide  inputs  to  incipient  activities. 


Library  Standardization 

Developing  standard  library  representations  for 
performance  models,  functional  models, 
reliability  models,  manufacturing  process 
models,  etc.,  arc  currently  not  being  addressed 
under  a  unified  standards  organization  and 
should  be  an  area  of  investment  under  the 
RASSP  program.  Any  progress  made  in  this 
direction  will  add  to  the  success  of  the  RASSP 
program. 

AVAILABILITY  OF  ENGINEERING 
ESTIMATE  MODELS  FOR  DESIGN, 
LOGISTICS,  AND  MANUFACTURING 
DATA 

The  Raytheon  RASSP  Design  System  concept 
relics  on  the  existence  of  models  at  various  levels 
of  abstraction  in  order  to  assess  the  cost,  risk, 
and  benefit  of  design  upgrades  and  in  order  to 
design  for  model  year.  Ensuring  the 
methodology  for  development  and  maintenance 
of  models  is  an  important  RASSP  investment 
area. 

ACTIONJTEM  3 

Subject:  Target  System  Application 
Domain 

Select  a  single  application  domain  that  would  be 
recommended  for  use  as  the  demonstration  model 
during  RASSP  development.  It  appears  that 
generalized  ATR  processor  model  that  has 
modular  options  to  accommodate  requirements  of 
Radar,  Sonar,  IR,  Laser,  MMW  Sensors  would 
be  most  suitable.  The  Target  programs  would 
be: 

•  Advanced  Land  Combat  Vehicle  (ALCVT) 

•  Joint  Direct  Attack  Munitions  (JDAM) 

•  Advanced  Kinetic  Energy  Missile  (ADKEM) 

•  Passive  Torpedo 

Detection/Classification/Localization  System 
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(DCLASP) 

•  Sonar  Mine  Detection  Set  (AN/AQS-20) 

•  Ground  Based  Radar  (GBR) 

•  Airborne  Shared  Aperture  Program  (ASAP) 


A  RASSP  program  option  would  be  to  use,  as  an 
initial  demonstration  model  the  Synthetic 
Aperture  Radar  (SAR)  processing  function  for 
both  JDAM  and  the  air  to  ground  portion  of 
ASAP.  Much  of  the  algorithm  technology  has 
been  derived  from  the  same  research.  A  common 
hierarchical  VHDL  model  sourced  from  program 
executable  specifications  would  contain  solutions 
for  both  systems.  The  VHDL  model  contains 
modular  options  and  parametrically  driven  design 
functions  that  would  be  assembled  into 
appropriate  hardware/software  demonstration 
models.  In  initial  program  phases,  scaled 
portions  of  the  system  would  be  used  to  exercise 
the  brokered  flexible  manufacturing  and  test 
resources.  As  the  RASSP  program  progresses, 
the  underlying  database  models  can  be  extended 
to  include  capabilities  for  additional  ATR 
functions  and  the  expanded  processor  needs  of 
other  system  programs  in  this  category.  This 
short  list  also  includes  two  sonar  applications, 
two  combat  vehicle/tank  applications  and  a  major 
ground  radar  system. 

2.0.3  General  Methodology 

The  study  process  involved  three  principal 
elements: 

•  The  personnel,  IR&D  and  contracts  currently 
involved  in  the  study  areas  within  Raytheon's 
four  divisions: 

•  Submarine  Signal  Division 
Portsmouth,  RI 

•  Missiles  Systems  Division 
Tewksbury,  MA 

•  Equipment  Division 
Marlboro,  MA 

•  Electromagnetic  Systems  Division 
Goleta,  CA 

•  Raytheon  performed  a  concerted  interviewing 
process  of  in-house  experts  and  of  industry 
resources.  Industry  resources  were 


expanded  to  include  standards 
groups/consortia,  service  laboratories, 
CAD/CAM/CAT  vendors  and  universities. 

•  The  data  gathered  was  analyzed  and  resulted 
in  suggested  approaches  and  feasibility. 
Feasibility  analysis  included  both  technical 
and  schedule  concerns.  Detailed 
recommendations  were  established. 

2.0.4  Technical  Results 

Raytheon's  Study  Phase  investigations  produced 
results  in  each  of  the  eleven  study  areas.  These 
results  are  listed  below. 

•  Established  a  promulgation  strategy  through 
phased  releases  and  design-system  structure 

•  Conceptually  linked  test-beds,  RASSP 
design-system  and  industry  resources 

•  Determined  team  structure,  expertise 
required,  and  sources  of  support 

•  Defined  aspects  of  design  methodology  to 
support  MODEL  YEAR  concept 

•  Developed  S/W  and  H/W  interoperability 
solution  sets  to  support  management  of 
MODEL  YEAR  upgrades 

•  Developed  RASSP  design-system  concept  - 
Framework,  tools,  standards 

•  Unique  design-system  features  -- 
Visualization,  electronic  data  books,  early 
assessment 

•  Strategy  for  test  which  reduces  all  costs  over 
product  life  cycle 

•  Conceptual  integration  of  RASSP,  ASEM, 
DICE,  PAP-E,  and  commercial  industry 

•  Structured  plan  for  integration  of  multi 
discipline  data  using  standards 

•  Target  system  selection  driven  by  grow'th  and 
volatility  of  threat 

2.0.5  Important  Findings  and 
Conclusions 

Significantly,  the  commercial  and  military 
industries  are  enthusiastically  in  support  of  a 
major  RASSP  initiative.  This  philosophical 
alliance  has  many  forces:  product  affordability, 
time  to  market  or  rapid  response,  open 
architectures,  standards,  logistics  and  a  growing 
evidence  of  the  importance  of  co-developments 
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or  shared  resources.  The  need  to  start 
immediately  was  evident.  The  initiative  would 
establish  the  urgency  and  focus  necessary  to 
attain  the  standards  (e.g.,  VHDL,  CALS,  CFI, 
etc.)  which  will  promote  increased  industry 
investment  in  the  tools,  methodology  and 
equipment  necessary  to  meet  the  market  places 
need  for  a  RASSP  development  process. 

In  many  application  areas,  the  requirements  for 
quickly  providing  state-of-the-art  processing 
throughput  at  affordable  life  cycle  costs  have 
outgrown  the  last  generation  development 
paradigm.  Two  areas  covered  in  some  detail  in 
this  report  are:  Automatic  Target  Recognition 
and  EW  processors.  Desert  Storm  experience 
was  reviewed  in  these  areas;  the  demands  of  fast 
response  and  advanced  algorithms  were  much  in 
evidence. 

The  systems  front  ends  of  CAD  systems  are 
lacking  today  and  demand  well  thought  out 
techniques  for  high  level  simulation,  requirement 
traceability  and  early  assessment  tools  supported 
with  advanced  visualization  techniques.  A 
RASSP  program  can  get  this  effort  started  on  the 
right  track  with  a  good  standard  foundation  and 
an  integration  of  the  most  promising  available 
tools.  A  longer  range  development  road  map  in 
this  area  is  also  important. 


It  has  become  apparent  that  expertise  and 
resources  are  available  but  highly  diverse.  The 
management  of  a  successful  RASSP  program 
must  address  this  complexity,  provide  guidance, 
selective  funding  and  intense  coordination. 
Universities,  national  laboratories,  service 
laboratories,  system  houses,  major  and  minor 
CAD/CAM/CAT/CASE  vendors,  manufacturing 
contractors,  and  standards  organizations  are  all 
part  of  this  resource  base.  It  is  a  national  effort 
that  must  involve  all  willing  participants. 

2.0.6  Significant  Hardware 
Development 

Raytheon  did  not  develop  any  hardware  under 
the  RASSP  Study  Phase  contract.  Raytheon's 
efforts  consisted  of  literature  searches, 
discussions  with  industry  leaders,  and 
development  of  documentation. 

2.0.7  Special  Comments 

Comments  pertaining  to  the  eleven  study  tasks 
are  found  within  Sections  3.1  to  3.1 1. 

2.0.8  Implications  for  Further 
Research 

Where  appropriate,  implications  for  further 
research  were  highlighted  within  Sections  3.1 
through  3.11. 
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3.0  Detailed  Study  Phase  Reports 

During  the  RASSP  Study  Phase,  the  Raytheon 
team  researched  applicable  CAE  tools  and 
methods  (commercially  available,  advanced 
research,  and  applicable  DoD  initiatives).  These 
are  presented  in  section  3.1  of  this  report. 
Included  with  the  list  of  tools  is  an  overview  of 
the  functionality  and  input  and  output 
mechanisms.  Some  of  the  tools  are  compatible 
with  the  use  of  standards  (for  input  modeling  and 
use  of  libraries)  within  the  current  tools. 

One  of  our  major  concerns  resulting  from  the 
investigations  was  the  successful  industry 
integration  through  promulgation  of  the  design 
system. 

To  realize  RASSP  goals,  the  block-one  RASSP 
Design  System  will  take  advantage  of  existing 
tools  and  methods  that  make  integration  easier. 
Early  proof-of-principle  can  be  completed  within 
the  first  year  of  the  RASSP  program.  The 
following  are  important  criteria  that  should  be 
followed  when  choosing  CAE  tools  to  integrate 
into  this  first  design  system. 

•  Functionality 

•  Use  of  modeling  standards  (VHDL,  Ada, 
Verilog,  etc.)  for  input  and  output 
mechanisms 

•  Integration  of  CAE  tool  with  standard 
libraries  for  COTS  parts 

•  Ease  of  Use 

•  Open  architecture 

•  Link  to  other  CAE  tools 

A  particularly  strong  effort  will  be  made  to 
incorporate  system  engineering  tools.  Functional 
descriptions  of  system  engineering  tools  are 
available  in  section  3.1  of  this  report.  Tools  are 
well  established  in  areas  such  as  software, 
hardware,  and  physical  design.  These  tools  are 
well  integrated,  and  take  advantage  of  current 
modeling  standards  and  libraries.  Currently, 
these  tools  conform  to  one  or  more  of  the  criteria 
described  above  and  therefore  can  be  integrated 


successfully  into  the  block-one  RASSP  Design 
System  within  the  first  year  of  the  program. 
However,  in  order  to  meet  long-term  RASSP 
goals,  many  other  design  system  elements  are 
important  Each  of  these  elements  is  explained  in 
Section  3.1. 

Promulgation  of  the  RASSP  design-system  and 
its  associated  product  data  models  can  be  attained 
by  providing  the  user  community  with  access  and 
involvement  during  the  RASSP  Implementation 
Phase.  Access  and  involvement  are  key  program 
elements  in  attaining  the  goal  of  widespread 
acceptance  and  use.  Access  to  an  operable 
system  throughout  the  course  of  the  development 
allows  hands-on  evaluation  that  benefits  both  the 
RASSP  contractor  and  the  industry  user.  Most 
major  DoD  contractors  and  commercial  system 
houses  invest  each  year  in  tool  evaluation  and  in 
decisions  to  upgrade  their  CAE  resources.  If  the 
program  plan  incorporates  a  phased  development 
where  sequential  block  releases  of  systems 
(block  1,  2,  3)  are  made  available  to  industry  at 
no  cost,  then  the  opportunities  for  interest,  use 
and  comments  from  the  user  community  are 
greatly  enhanced. 

Block  1,  2,  and  3  of  the  design  system  must 
make  sense  to  the  RASSP  program  and  to  the 
user  community.  Block  1  would  result  from  the 
integration  of  available  tools  placed  on  available 
frameworks  (Mentor,  Cadence,  Compass). 
Tools  and  standards  would  be  strongly  based  on 
VHDL  in  its  latest  form(s).  Block  2  would  take 
advantage  of  on-going  initiatives  in  commercial 
CAE,  RASSP  funded  advanced  development, 
DICE,  MADE,  MANTECH  -  that  fit  the 
timeline.  Full  CFI  standards  would  tie  the 
system  together.  Block  3  would  be  the  RASSP 
design  system  and  incorporate  suitable  results  of 
research  activity  and  lessons  learned  from  block 
1  and  2.  Raytheon  anticipates  that  the  user 
community  would  be  proactive  in  their  evaluation 
and  perhaps  propose  additional  projects  for 
contract  consideration.  Maturing  university 
research  would  also  be  transitioned  into  the  block 
3  system.  Block  3  is  obviously  the 
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commercialization  baseline  with  the  justifying 
econometrics  being  provided  by  increased  user 
activity  and  system  driven  demonstrations. 
Figure  3.0-1  is  a  pictorial  of  this  phased 
development.  Block  1  provides  a  baseline. 
Block  2  resolves  many  of  the  issues  related  to  the 
current  technology.  Block  3  addresses  evolving 
technology  and  attempts  to  avoid  the  “generation 
gap”  that  often  exists  between  mature/highly 
efficient  CAE  and  the  advanced  hardware 
technology  it  addresses.  An  example  of  the  last 
issue  might  be  the  CAE  necessary  to  manage  the 
“power  and  parasitics”  of  several  hundred 
megacycle  component  interconnections. 

Another  example  might  be  the  ability  to  use 
assessment  toe’s  within  a  framework  when 
“look-ahead”  ad  hoc  CAE  design/analysis 
tools  are  used  ior  next  generation  product  models 
(next  model  year  interoperability  issues).  There 


are  many  exciting  possibilities  that  will  come 
from  research  of  design  systems,  languages,  and 
system  test  bed  interfaces  which  can  be  placed 
within  the  Block  3  framework  and  be  allowed  to 
mature  even  beyond  the  RASSP  contract. 

Involvement  requires  a  system  of  selectable 
assets  for  use  by  the  industry.  Figure  3.0-2 
highlights  the  idea  of  a  multi-dimensional  design 
system  structure.  Essentially,  the  structure  can 
be  viewed  as  partitioned  (perhaps  virtually)  into 
“functions”  represented  horizontally.  Vertically, 
each  function  has  a  tool  set,  data  types  and 
standards  that  are  not  necessarily  exclusive  to  the 
particular  functional  domain.  The  advantages  of 
this  structure  are  several.  The  military  systems 
house,  the  commercial  systems  house,  or  the 
commercial  CAE  vendor  can  gain  access  to  a 
particular  segment  of  interest  without  resorting  to 
a  complete  resource  commitment.  For  example. 
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Figure  3.0-1,  Phased  Development  Of  The  RASSP  Design  System 
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a  commercial  CAE  developer  may  find  an 
increasing  market  for  assessment  tools  and 
decide  to  focus  their  investment  strategy  in  this 
area.  Many  other  combinations  of  business  and 
development  situations  can  be  envisioned.  The 
system’s  structural  focus  on  standards  and  the 
way  in  which  functions,  tools,  libraries, 
manufacturing  resources  and  test  bed  interfaces 
communicate  throughout  the  design  process 
provides  an  excellent  environment  for  evaluation 
of  upgrades,  and  additional  language  constructs 
and  translators.  This  data  is  also  made  available 
through  networked  bulletin  boards  to  the  user 
community  for  comment  and  to  the  standards 
committees  for  consideration  and  potential  action. 

To  meet  program  objectives  RASSP  products 
will  rely  heavily  on  ASICs  and  MCMs  to  realize 
the  upgradability  of  the  model  year  approach. 
Design  agencies  will  need  to  have  access  to  ASIC 
and  MCM  suppliers,  and  will  demand  flexibility 


in  how  the  interface  is  executed.  While  the  ASIC 
industry  is  fairly  well  established,  the  MCM 
industry  is  in  its  infancy.  Access  to  Application 
Specific  Electronic  Modules  (ASEM)  foundries 
will  be  facilitated  by  common  electronic  data 
exchange  and  an  electronic  brokering  system. 
The  ASEM  brokering  service  would  provide  a 
mechanism  for  managing  the  acquisition  of 
ASEMs  through  multiple  suppliers.  The  broker 
manages  the  relationships  with  IC  and  MCM 
suppliers.  This  reduces  the  number  of 
relationships  to  be  managed  by  the  design 
organizations.  The  broker  would  be  responsible 
for  qualifying  suppliers,  understanding  vendor 
capabilities  and  particular  areas  of  expertise,  and 
responding  to  customer  needs. 


Figure  3.0-2,  Multidimensional  Design-System  Structure 
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2J _ Design  and  Design-System 

Reguirements 

An  important  element  of  the  RASSP  program  is 
the  RASSP  Design  System.  The  design  system 
provides  a  support  environment  in  which  RASSP 
designers  can  assess  the  cost,  risk  and  benefit  of 
design  upgrades  early  in  the  design  cycle  and 
provides  a  seamless  environment  for  designing 
the  present  model  year  system.  Given  the 
RASSP  model  year  concept,  the  designer  needs 
to  design  today  with  look-ahead  knowledge  for 
two  to  three  model  years.  The  assessment 
criteria  takes  into  account  design  information 
(such  as  the  latest  or  next  generation  packaging 
technology  or  signal  processing  algorithm,  etc.) 
but  also  takes  into  account  manufacturing 
information  (such  as  supplier  capabilities  - 
current  and  future,  costs,  lead  time,  etc.)  and 
logistics  information  (such  as  field  test 
equipment,  spares,  etc.).  All  of  this  data,  if 
presented  early  enough,  provides  a  good  baseline 
for  determining  the  feasibility  of  the  upgrade 
prior  to  doing  any  detailed  design  or 
mamrfacturing. 

This  section  of  the  final  report  is  organized  as 
follows: 

•  Study  Phase  Accomplishments 

•  Overview  of  the  RASSP  Design  System 
Architecture  Concept 

•  Detailed  description  for  each  element  of 
the  RASSP  Design  System  Architecture 
Concept 

•  RASSP  Design  System  interface  to  the 
CALS  delivery  standards 

•  Major  Issues  to  be  addressed  during 
development  of  the  RASSP  Design 
System 

•  Relevant  Raytheon  related  efforts 

3.1.1  Study  Phase 
Accomplishments 

As  a  result  of  the  RASSP  study  contract,  a 
concept  was  developed  for  a  system  design 
environment  which  improves  the  design 


capabilities  available  to  the  designer  early  in  the 
design  cycle  and  allows  for  the  assessment  of  the 
impact  of  implementation  architecture  and 
technology  on  a  system. 

One  of  the  key  concepts  is  the  development  of  an 
environment  that  has  access  to  design, 
manufacturing  and  logistics  engineering  estimate 
and  historical  data.  Access  to  historical  logistics 
data  allows  the  designer  to  assess  design  trade¬ 
offs  based  on  historical  support  data  and  allows 
the  designer  to  address  historical  support 
problems  in  the  updated  design.  For  new 
designs,  historical  data  may  not  be  available.  For 
these  cases,  engineering  estimates  can  be  derived 
based  on  similar  systems  in  the  field  or  through 
theoretical  models.  Historical  and  estimated 
manufacturing  data  is  also  beneficial  early  in  the 
design  cycle.  This  information  allows  the 
designer  to  address  prior  manufacturability 
problems  as  the  design  is  updated,  as  well  as 
assessing  the  manufacturability  of  the  design, 
available  manufacturers,  and  the  projected 
manufacturing  cost. 

A  major  portion  of  this  phase  was  a  study  of  the 
current  state-of-the-art  and  advanced  research  in 
CAE  tools  and  methodologies.  The  team 
assessed  the  applicability  of  integrating  CAE 
tools  from  the  current  commercial  CAE  industry. 
Additionally,  applicable  advanced  research 
currently  underway  at  universities  or  through 
funded  DoD  initiatives  was  reviewed  to  fill  in 
functional  holes  or  incomplete  solutions  in  the 
design  system.  Included  in  this  report  is  a  set  of 
detailed  matrices  that  outline  various  CAE  tools 
available  commercially  or  through  advanced 
research  avenues.  Table  3.1-1  summarizes  the 
basic  design  activities  surveyed  under  the 
RASSP  Study  .  Although  there  are  tools  for 
every  activity  of  the  design  process  listed,  the 
utility  of  the  tools  is  limited  since  they  are  not 
well  integrated.  Many  have  their  own  specialized 
data  representation,  and  data  entry  means.  In 
addition,  some  tools  do  not  easily  lend 
themselves  to  use  by  designers  due  to  the 
knowledge  required  to  operate  them  effectively. 
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The  key  issues  in  the  development  and 
integration  of  tools  under  RASSP  is  the 
development  and  integration  of  the  tools  via 
standards,  the  development  of  a  consistent  means 
of  invoking  and  interacting  with  the  tools,  and 
the  ability  to  generate  standard  interchange 
formats  to  meet  CALS  deliverable  requirements. 

Design  Activities 
Requirements  Design  and  Analysis 
Concept  Design  and  Analysis 
Softw^  Design  and  Analysis 
Hardware  Design  and  Analysis 

Physical  Design  and  Verification _ 

Test  Generation 
Documentation 


TABLE  3.1-1,  RASSP  DESIGN 
ACTIVITIES 

As  part  of  the  investigation  of  CAD  design  tools, 
a  number  of  standards  were  investigated.  The 
number  of  standards  which  impact  CAD  tools  is 
large.  They  include  the  CFI  standards  for  tool 
integration,  the  EDIF  standards  for  data 
exchange,  and  standard  languages  for  design  and 
simulation  (e.g.  VHDL).  However,  additional 
standards  must  be  considered  to  allow  a 
consistent  user  interface,  and  the  development  of 
portable  software.  These  standards  are  listed  in 
Table  3.1-2.  Any  RASSP  funded  software 
should  be  consistent  with  these  standards,  as 
well  as  CFI  and  IEEE  standards,  to  assure  the 
implementation  will  not  be  obsolete  in  the  near 
term,  and  that  the  software  will  be  easily  poned 


to  new  platforms  in  the  rapidly  changing 
workstation  and  PC  marketplace.  Knowledge  of 
the  above  mentioned  standards  are  key  to  the 
development  of  a  seamless  design  environment 
that  is  usable,  extensible,  supportable  and 
portable. 

As  previously  indicated,  standards  are  an 
important  technology  for  RASSP.  We  have 
evaluated  some  of  the  key  standards  such  as 
VHDL  and  CFI  to  understand  their  implications. 
A  major  concern  to  the  RASSP  project  is  the 
length  of  time  required  to  issue  and  update 
standards.  As  an  example,  VHDL  is  currently 
undergoing  a  revision,  however,  analog  issues 
are  not  being  considered  for  the  1992  release, 
which  means  they  will  not  be  available  until  the 
year  1997  at  the  earliest,  since  IEEE  standards 
are  reviewed  on  a  5  year  basis.  In  other  areas 
such  as  CFI,  the  initial  standards  will  be  voted  on 
in  1992,  however,  additional  standards  as  well  as 
updates  to  the  standards  will  be  required  to 
support  RASSP.  It  is  not  clear  that  large  funding 
will  greatly  increase  the  speed  of  the  standards 
work,  or  the  development  of  standards  where 
none  exist  today.  The  adoption  of  standards  is 
voted  on  by  representatives  of  commercial  firms, 
DoD  contractors,  universities  and  the  DoD.  It  is 
important,  therefore,  to  identify  standards  work 
that  is  of  importance  to  RASSP  and  to  influence 
voting  representatives  to  push  strongly  for  those 
standards.  One  manner  of  doing  this  is  through 
RASSP  implementation  phase  teaming 
arrangements  with  voting  CAD  members. 


Standard 

Organization 

Name  of 
Standard 

Area  of  Applicability 

lEFF. 

POSK 

Software  standards  to  assure  portability 

ANSI 

Various 

Computer  languages,  graphics  standaids,  and 
networking  standards 

OSf 

OSf/dCe 

Interoperability  standard 

"USf 

OSF/Motif 

Graphical  user  interface  standard 

UI 

UNIX 

Interoperability  standards 

X  Consortium 

X  Windows 

Protocol  for  base  level  graphics 

TABLE  3.1-2,  SOFTWARE  DESIGN  STANDARDS 
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Additionally,  the  RASSP  Design  System  will  be 
incrementally  upgraded  and  made  available  for 
evaluation  three  times  throughout  the 
implementation  phase  thereby  giving  non-team 
members  a  view  of  the  product  and  the  direction 
that  CFI  should  head. 

A  key  consideration  in  the  proposed  RASSP 
contract  will  be  the  split  of  funding  between  the 
development  and  enhancements  of  tools,  versus 
the  integration  of  tools  via  standards.  A  mixture 
of  each  activity  is  required,  however,  it  is 
imponant  to  look  at  the  benefits  to  be  derived 
from  improved  synthesis  and  assessment  tools 
for  the  system  designer  versus  improve  ease  of 
use  of  currently  used  tools  at  the  logic  and 
physical  design  stages.  Areas  which  are  ready 
for  exploitation  include:  executable 
specifications,  requirements  flow  down, 
automatic  system  partitioning  into  commercially 
available  parts,  availability  of  models  for  design, 
manufacturing  and  logistics  information, 
improved  insertion  of  testability  at  all  levels  of 
the  design,  and  improve  manufacturability 
analysis  prior  to  release  to  manufacturing.  For 
RASSP  to  be  successful,  a  careful  funding  trade¬ 
off  must  be  performed  between  integration  via 
standards  which  is  occurring  today  without 
RASSP  funding,  and  the  acceleration  of  the 


development  of  tools  which  are  non-existent  or  in 
the  prototype  stage  today. 

Some  of  the  technical  challenges  for  improving 
the  CAD  tools  above  are  being  addressed  in  a 
number  of  DOD  and  DARPA  initiatives.  These 
initiatives  include  DICE,  MADE,  VTEST,  etc. 
These  programs  should  be  leveraged  by  RASSP 
to  eliminate  duplicate  funding  and  use  RASSP 
funds  to  address  needs  not  met.  Table  3.1-3  lists 
a  sample  of  the  on-going  and  proposed  effons 
which  should  be  monitored  for  inclusion  in  the 
RASSP  program. 

3.1.2  Overview  of  the  Design 

System  Concept 

Figure  3.1-4  depicts  the  RASSP  Design  System 
architecture  concept  developed  under  the  study 
phase  contract.  The  concurrent  engineering 
system  provides  a  design,  analysis,  assessment 
and  documentation  environment  for  hardware 
and  software  codesign. 

The  design  system  will  be  implemented  using 
commercial  framework  tools  such  as  Mentor's 
Falcon  framework  and  Cadence’s  Framework.  It 
will  be  developed  using  the  framework  standards 
for  tool  and  data  integration  and  communication 
as  defined  by  CFI.  CAE  tools  will  be 
encapsulated  and  integrated  into  the  design 


Program  Name 

Objective 

DICE  (DARPA) 

Development  and  demonstration  of  enabling 
technologies  for  concurrent  engineering 

Simulatable  Specifications 
(Wright  Laboratories) 

Develop  guidelines/  methodologies  and  CAD  tools 
to  suppon  the  use  and  integration  of  simulatable 
specifications 

PAP-E  (Wright 
Laboratories) 

PDES  Application  Protocols  for  electronics 

VTEST  (Wright 
Laboratories) 

Development  of  a  virtual  test  environment  to 
support  multiple  testers 

Multi-Component 

Synthesis  (Wright 
Laboratories) 

Extend  high-level  partitioning  and  synthesis 
algorithms  and  tools  for  multi-component  devices 

TABLE  3.1-3,  DARPA  AND  DOD  PROGRAMS  OF  INTEREST  TO 

RASSP 
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Figure  3.1-4,  RASSP  Design  System  Architecture  Concept 


framework.  There  are  four  main  elements  of  the 
system: 

1 .  Design  System  Framework  (discussed  in 
section  3. 1.2.1) 

2 .  Analysis  Recording  and  Assessment 
Tools  (discussed  in  sections  3.1.2.2.x) 

3 .  Concurrent  Engineering  Product  Design 
Tools  (discussed  in  section  (3. 1.2.3) 

4 .  Product  Data  Models  that  support  the 
design  system  (discussed  in  sections 
3.1.2.2.x) 

Each  of  the  four  parts  of  the  design  system  will 
be  discussed  in  more  detail  throughout  the 
remainder  of  section  3.1.2. 


The  CFl  mission  is  synergistic  with  other 
industry  standards  efforts,  such  as  the  Open 
Software  Foundation  (OSF),  the  Electronic  Data 
Interchange  Format  (EDIF)  and  the  government 
funded  Engineering  Information  System  (EIS) 
program.  Raytheon  Company  has  a  subscription 
membership  to  the  CAD  Framework  Initiative 
and  has  been  closely  tracking  the  activities  of 
CFI.  Much  of  the  work  of  CFI  is  now 
documented  in  the  draft  specifications,  user 
guides,  reference  software  and  regression  tests. 
CFI  refers  to  this  collection  of  items  as  CFI  Pilot 
Release  1.0.  It  includes  the  following  draft 
standards: 


3. 1.2.1  Design  System  Framework 

In  recent  years,  an  EDA  standards  organization, 
the  CAD  Framework  Initiative  (CFI),  was 
founded  to  develop  a  framework  standard  for 
CAD  tools.  CFI  is  an  international  cooperative 
effort  within  the  electronics  industry.  CFI 
believes  that  a  framework  should  be  a  layered 
procedural  interface,  supported  on  multiple 
platforms,  that  is  modular  and  easily  extensible. 


•  Design  Representation  Electrical 
Connectivity  Information  Model  and 
Programming  Interface 

•  Inter-Tool  Communication  Procedural 
Interface 

•  Inter-Tool  Communication  Architecture 

•  Inter-Tool  Communication  Base  Object 
Model  and  Interface 

•  Tool  Encapsulation  Specification 

•  Execution  Log  Format 
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•  Base  Networking  Services  Guidelines 

•  Base  System  Services  Guidelines 

•  CFI  Users,  Goals  and  Objectives 

The  above  standards  will  i>artially  address  many 
of  the  areas  required  for  RASSP  including 
Incremental  Change/Analysis,  Tool  Invocation 
and  Control  and  a  Standard  Extension  Language. 
CFI  has  defined  a  plan  that  suppons  RASSP. 
This  plan  consists  of  four  Integration  Phases: 
Phase  0-EDA  Systems  Integration,  Phase  1- 
Manufacturing  Integration,  Phase  2- 
CASE/Codesign  Integration,  and  Phase  3- 
Enterprise  Integration.  What  CFI  brings  to  the 
RASSP  program  is  a  model  for  developing 
framework  standards.  CFI  has  been  successful 
in  selecting  a  specific  problem,  getting  large  end- 
user  companies  experiencing  the  integration 
problem  to  participate,  and  getting  vendors  to 
work  together  to  solve  the  end-users  problem  by 
developing  the  appropriate  standards.  CFI’s 
RASSP  funding  requests,  totaling  $4.1  million 
over  4  years,  covers  CFI's  costs  of  coordinating 
the  framework  standards  development  effort.  It 
includes  the  cost  of  a  program  manager,  general 
support  to  the  vendors  and  end-users, 
development  of  specifications,  technology,  and 
regression  tests.  It  does  not  include  the  costs 
incurred  by  the  vendors  or  end-users  involved  in 
the  standards  development  effort.  However,  CFI 
has  been  successful  in  the  past  in  getting 
companies  to  volunteer  their  own  time  and  effort 
to  develop  the  standards. 

CFTs  RASSP  Phase  0  and  CFI's  release  2,0: 
CFI's  release  2.0  should  complete  CPTs  work  in 
the  EDA  area  including  specifications  for  a  Multi¬ 
simulator  Backplane  and  Library  Standards. 
Process  Management  and  Data  Management 
standards  are  just  beginning  to  be  addressed. 
CFI  admits  that  there  is  still  much  work  to  do  in 
these  areas,  specifically  regarding  namespace 
resolution,  and  that  without  additional  attention, 
standards  will  not  be  available  in  the  short  term. 
Without  funding  from  the  RASSP  program,  the 
EDA  interfaces  (CFI's  release  2.0)  will  almost 
certainly  be  created  anyway.  These  projects  have 


already  begun.  By  adding  additional  funding, 
the  RASSP  program  would  have  some  influence 
in  determining  the  release  2.0  delivery  date  and 
would  be  able  to  ensure  that  the  RASSP 
problems  were  addressed.  Without  RASSP 
involvement,  these  standards  will  probably  be 
delivered  3-6  months  later  than  they  would  with 
RASSP  involvement. 

CFI's  RASSP  Phase  1:  The  RASSP  program 
could  have  a  far  greater  influence  in  the 
Manufaemring  interfaces.  These  programs  are 
still  in  the  vision  stage  and  there  exists  the 
possibility  that  they  may  not  get  off  the  ground  at 
all  without  government  input.  Raytheon's 
general  belief  is  that  these  manufacturing 
interfaces  would  be  developed  by  CFI  regardless 
of  the  involvement  of  the  RASSP  program. 
However,  they  would  probably  be  developed  at  a 
slower  pace. 

CFI's  Phases  2  and  3:  As  for  standards  for 
CASE/Codesign  and  Enterprise  integration, 
RASSP  could  play  a  major  role.  This  is  basically 
a  “cottage  industry”  with  no  standardization.  The 
RASSP  program  would  have  a  large  impact  in 
this  technology  area.  Without  RASSP 
involvement,  there  is  a  chance  these  areas  will 
not  be  addressed  at  all.  Phase  2  and  3  can  not  be 
accomplished  within  the  RASSP  program  time 
frame,  but  the  RASSP  design  system  will 
provide  an  implementation  that  will  seed  further 
CFI  standards  development  in  these  areas. 

The  suggested  approach  is  to  have  DARPA  fund 
a  number  of  resources  which  will  be  available  to 
all  the  RASSP  contractor  teams.  These  may 
include  CFI  and  NIST.  CFI  will  provide  general 
support  and  consulting.  This  funding  will  also 
help  CFI  in  development  of  specifications, 
technology,  and  regression  tests.  The  contractor 
team  should  have,  as  team  members,  at  least  two 
framework  companies  and  a  group  of 
CAD/CAM/CASE  vendors.  Working  with  two 
framework  companies  will  ensure  that  the  design 
system  is  not  vendor  specific.  The 
CAD/CAM/CASE  vendors  will  provide  the 
needed  design  functions  within  the  frameworks. 
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The  contractor  team  will  insure  that  the  developed 
design  system  will  meet  RASSP  goals  and 
conform  to  CFI  standards.  Within  this  team 
and  support  structure,  RASSP  and  framewc  .. 
houses  will  be  coordinating  releases  of  the 
RASSP  design  system. 

The  main  reason  for  this  approach  is  to  reduce 
the  risk  of  CAD/CAM/CASE  vendors  not 
participating  and  conforming  with  standards. 
CFI's  plan  depends  on  vendors  participating 
voluntarily.  Given  that  many  vendors  are 
already  involved  with  current  CIT  activities  on 
their  own  funding,  can  they  afford  more  free 
involvement?  Also,  some  of  the  small  vendors 
that  will  provide  critical  functions,  may  not  have 
the  resources  to  provide  donations.  This 
approach  will  also  expedite  the  standards 
development  because  real  application 
implementation  and  demonstration  will  accelerate 
the  development  process. 

With  regard  to  CFI  releases  and  Raytheon's 
concept  of  block  releases:  our  block  releases  will 
conform  to  whatever  is  available  at  the  time. 
Releases  are  not  necessarily  marketable  entities 
but  are  a  structured  design  system  made  available 
to  industry  for  evaluation. 

•  Block  One  Design  System: 

•  Not  all  EDA  Systems  integration 
standards  will  be  ready.  The  contractor 
will  bring  the  design  system  (with  its  tool 
sets)  to  the  CFI  release  1. 

•  Block  Two  Design  System: 

•  The  design  system  will  conform  with  CFI 
release  2.  There  will  also  be  some 
implementation  of  manufacturing 
integration  that  will  be  coordinated  with 
CFI. 

•  Block  Three  Design  System: 

•  The  design  system  will  upgrade  its 
manufacturing  integration  interface  to 
CFI's  manufacturing  integration 
standard.  Block  release  3  will  also  start 


the  implementation  of  CASE/codesign 
integration.  This  implementation  will 
contribute  to  CFI's  CASE/codesign 
integration  effon. 

In  addition  to  the  EDA  framework,  there  is  a 
need  for  a  design  process  framework  ;c  control 
the  flow  of  design  data  and  the  sequencing  of 
CAD  applications.  Process  control  capabilities 
have  been  implemented  on  existing  frameworks 
for  modeling  static  flow.  The  RASSP  design 
system  should  leverage  the  dynamic  process 
control  mechanisms  that  are  available  through 
DARPA's  Initiative  In  Concurrent  Engineering 
(DICE)  sponsored  Computer-Aided  Concurrent 
Engineering/  Process  Modeler  (CACE/  PM)  tool 
developed  by  Perceptronics  and  by  the 
methodology  developed  by  Carnegie  Mellon 
University  using  the  Statemate  tool.  CACE/  PM 
is  a  process  modeling  and  simulation  software 
package  that  supports  modeling  and  analysis  of 
the  product  development  processes  in  terms  of 
resource  requirements,  schedule,  timelines, 
budgets,  resource  utilization  time  and  cost,  and 
activity  flows.  While  EDA  frameworks  suppon 
tool  integration,  CACE/  PM  supports  process 
integration  which  is  essential  to  concurrent 
engineering  and  allows  the  definition  of  metrics 
to  measure  development  progress.  The 
CACE/PM  tool  is  currently  encapsulated  and 
running  both  stand-alone  and  under  Mentor's 
Falcon  framework.  Figure  3.1-5  shows  the  flow 
of  the  CACE/  PM  tool. 


Figure  3.1-5,  Flow  of  the  CACE/PM 
Tool 


For  the  software  development  environment,  a 
process  modeling  and  analysis  capability  has 
been  researched  and  successfully  implemented  by 
Carnegie  Mellon  University's  (CMU)  Software 
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Engineering  Institute  (SEI).  Raytheon  has  used 
this  methodology  to  model  and  analyze  the 
software  process  through  the  use  of  the  Statemate 
tool  from  i-Logix,  Inc.  Statemate  provides  a 
representation  formalism  that  is  highly  visual,  yet 
formally  defined.  Three  types  of  diagrams  are 
used  to  represent  different  perspectives  of  a 
process:  1)  Functional  perspective  (Figure  3.1-6) 

-  representing  what  functions  are  being 
performed,  and  what  information  flows  are 
pertinent  to  the  functions;  2)  behavioral 
perspective  (Figure  3.1-7)  -  representing  when 
tasks  are  performed,  along  with  feedback  loops, 
iteration,  complex  decision-making  conditions, 
etc.;  3)  organizational  perspective  (Figure  3.1-8) 

-  representing  which  organizational  units  perform 
the  tasks  and  the  physical  communications 
mechanisms  used  for  information  transfer.  One 
of  the  goals  of  the  CMU  project  was  to  facilitate 
the  management  of  a  software  development 
process  to  provide  a  basis  for  measurements, 
metrics,  and  data  collection.  Both  of  these 
methodologies  should  be  looked  at  for  potential 
application  to  RASSP. 


Figure  3.1-6,  Statemate  Functional 
Perspective 


Figure  3.1-7,  Statemate  Behavioral 
Perspective 


Figure  3.1-8,  Statemate  Organizational 
Perspective 


3.1.2.2.1  Assessment  Tools 

In  the  design  of  systems,  one  of  the  current 
deficiencies  in  the  tool  suite  is  the  lack  of  high 
level  assessment  tools  that  use  engineering 
estimate  and  historical  data  to  drive  the 
assessments.  The  availability  of  this  assessment 
capability  would  improve  the  accuracy  of  trade¬ 
off  studies  performed  early  in  the  design  cycle. 
Historically  the  costs  associated  with  design, 
manufacturing  or  logistics  has  not  been  made 
available  to  the  system  designer  to  allow  that  data 
to  influence  the  updated  design.  One  of  the 
major  achievements  of  the  integration  of 
assessment  tools  and  a  historical  database  would 
be  to  make  information  available  to  the  designers 
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-  threat  data 

-  technology  data 

-  test  data 

-  performance  data 

-  historical  data 

-  R&M  data 


Figure  3.1-9,  Examples  of  Estimate  Data  Elements 


and  the  assessment  tools  which  will  improve  the 
design  based  on  actual  field  support  data,  such  as 
ease  of  fault  identification  and  isolation,  repair 
time  due  to  accessibility  of  components,  and  part 
failure  rates.  Similarly  for  manufacturing, 
information  on  part  availability,  production  lead 
times,  and  manufacturing  capability  play  an 
important  role  in  the  design  trade-off  analysis  of 
a  system.  Figure  3.1-9  is  an  example  of  data 
elements  which  would  be  analyzed  by  the 
assessment  tools. 

Another  difficulty  with  the  current  assessment 
tools  is  access  to  the  appropriate  type  of  data. 
That  is,  in  the  early  phases  of  a  design,  the  use  of 
historically  extrapolated  engineering  estimate  data 
would  be  sufficient  if  available.  The  challenge  is 
to  meet  the  needs  of  the  tools  given  their  level  of 
granularity  and  detail  with  supporting  data  at  the 
same  level.  For  example,  knowing  that  a  system 
is  composed  of  30  modules  and  an  average 
module  cost  of  $100K  for  design  and 


prototyping  may  be  adequate  for  a  high-level  of 
analysis.  However,  when  the  module^,  are 
defined  in  more  detail  (as  to  functions, 
components,  and  structure),  current  design, 
logistics  and  manufacturing  cost  models  can  be 
used  to  give  an  accurate  estimate  of 
manufacturing  cost.  The  concept  of  the  data 
hierarchy  is  illustrated  in  Table  3.1-10. 

3. 1 .2,2,2  Electronic  Design  Notebook 

In  the  design  of  electronic  systems,  considerable 
effort  goes  into  the  formal  documentation  of  the 
system.  However,  there  is  also  a  large  amount 
of  missing  information.  In  the  process  of 
designing  a  circuit,  the  design  engineer  makes 
many  decisions  regarding  the  selection  of  parts, 
critical  component  placement,  critical  signal 
timing,  and  other  information  which  is  lost.  In 
addition,  information  concerning  the  intent  of 
function  of  the  circuit,  and  the  rational  for  its 
design  are  also  not  documented.  Thus  upon  re¬ 
design  or  updating  by  another  engineer,  the 


Design  Phase 

Required  Data 

Requirements  Development 

Historical  extrapolated  engineering  estimates 

Concept  Development 

Technology  data  (current  and  look-ahead) 

Detail  Design 

Actual  engineering  data 

TABLE  3.1-10,  DATA  HIERARCHY 
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infonnation  in  the  original  designer's  head  is  not 
available,  and  has  not  been  captured  in  the 
technical  data  package.  With  the  electronic 
notebook  the  designer  would  be  able  to  easily 
add  notes  to  the  design  he  is  working  on,  and 
thus  easily  document  all  his  detailed  design 
decisions,  and  their  rational.  The  key  issues  for 
this  notebook  to  woric  effectively  are  ease  of  use, 
non-intrusive  to  the  design,  and  availability 
during  all  phases  of  the  design.  Information 
retrieval  system  and  organization  structure  of  the 
data  in  the  notebook  are  requirements.  Work  in 
this  area  was  performed  under  the  DICE  contract 
resulting  in  a  product  referred  to  as  the  Electronic 
Design  Notebook  (EDN).  This  system  was 
based  on  the  FRAMEMAKER  tool,  with  dialog 
boxes  and  menus  developed  to  ease  the  designers 
access  to  the  notebook  and  data  entry.  The 
system  allows  the  entry  to  not  only  textual  data 
but  also  graphical  and  spreadsheet  data.  Figure 
3.1-1  la  illustrates  the  Electronic  Design 
Notebook  concept.  This  capability  should  be 
integrated  into  the  design  environment  under 
RASSP,  since  it  is  gaining  acceptance  in  the 
industry,  and  STEP  will  provide  a  capability  to 
store  this  information. 


Figure  3.1-lIa,  Electronic  Design 
Notebook  Concept 


3.1.2.2.3  Electronic  Design  Databook 

In  order  for  a  system  to  be  upgraded  efficiently 
and  effectively,  the  current  designers  must  gain 
an  understanding  of  the  original  design  and  must 


work  in  a  design  system  environment  for 
concurrent  engineering.  To  do  that  requires  a 
combination  of  the  electronic  design  notebook 
together  with  an  electronic  design  databook.  The 
electronic  design  databook  provides  immediate 
access  to  design  data  from  the  original  and 
current  design  while  the  electronic  design 
notebook  provides  access  to  the  rationale  for 
original,  current,  and  look-ahead  design 
decisions.  Access  to  design  information  includes 
test  files,  simulation  results,  design  schematics, 
documentation,  etc.  Today,  designers  can  spend 
a  considerable  amount  of  time  tracking  down  the 
correct  revision  and  location  of  an  electronic  test 
file  or  design  schematic.  To  assess  the  impact  of 
a  design  change,  the  electronic  design  databook 
will  provide  automatic  access  to  the  appropriate 
simulator  used  to  analyze  the  design  and  test  file 
format  that  has  changed.  Figure  3.1-1  lb  shows 
the  Electronic  Design  Databook  concept. 


OMfOaiM:  > 


ProvIdM  Automatic  Elactranic  Accaoa  to: 
.  Daaign  data 
•  Toot  lUaa 
.  Simulators 


Figure  3.1-llb,  Example  of  Electronic 
Databook  Concept 

Currently  available  commercial  frameworks 
provide  a  portion  of  this  capability  through  the 
static  process  flow  capabilities.  Additionally, 
there  exists  some  commercial  products  that  can 
be  incorporated  into  the  databook  concept.  An 
example  is  on-line  access  to  component  data. 
Designers  spend  considerable  time  searching 
through  data  books  to  select  parts  which  meet  the 
specifications  for  their  design.  Some  systems, 
such  as  CAPS,  provide  on-line  access  to  textual 
data,  however,  the  extraction  of  the  data  for 
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simulation  or  other  electrical  analysis  is  manual. 
ASPECT  has  developed  a  system  which  is 
beginning  to  meet  the  needs  of  the  designer  with 
an  on-line  search  and  extraction  capability.  More 
effort  is  needed  to  format  the  extracted  data  for 
the  analysis  tools.  Data,  such  as  schematic 
symbols  with  the  proper  data  annotation, 
physical  models  for  physical  design  and 
manufacturing  checks,  simulation  models,  and 
data  for  cost.  This  is  an  area  where  standards  for 
databook  formats,  and  standards  for  interfacing 
to  analysis  tools  would  benefit  the  users. 
Currently  CFI  under  the  Component  Information 
Representation  (CIR)  Technical  Subcommittee 
(TSC)  is  developing  a  standard  for  the 
component  database,  with  a  draft  specification 
due  in  mid- 1993. 

3.1. 2,2,4  Visualization  Techniques 

Until  now,  this  report  has  focused  on  the 
gathering  and  analysis  of  design  data.  This 
section  deals  with  the  presentation  of  that  design 
data.  From  research  into  virtual  reality  and 
visualization  techniques,  the  interpretation  of 


complex  data  is  realizable  by  many  individuals 
representing  different  disciplines.  Through 
research  conducted  at  the  University  of  San 
Francisco,  Professor  Bradford  Smith  stated  that 
"The  ability  of  many  individuals  to 
simultaneously  view  the  display  and,  using  their 
disparate  experiences,  negotiate  the  meaning  of 
past  data  and  likelihood  of  possible  futures  is  a 
major  strength  of  this  analysis  and  presentational 
technique." 

To  apply  this  concept  to  RASSP  needs,  the  team 
looked  at  the  use  of  visualization  techniques  in 
the  design  system,  for  the  display  of  complex 
design,  logistics,  and  manufacturing  data.  To  the 
expert  in  those  disciplines,  a  detailed  Mentor 
analysis  or  fault  tolerance  analysis  report  or 
perhaps  the  supplier's  process  capabilities  etc. 
would  be  the  best  view  on  the  data.  Without  the 
details,  the  interpretation  of  the  results  would  not 
be  as  exact  or  complete  as  necessary.  However, 
to  the  designer  attempting  to  make  an  informed 
decision  based  on  the  process  capabilities  or  life- 
cycle  cost  model,  the  details  of  that  raw  data  are 
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too  complex  to  be  of  immediate  use.  In  the  case 
of  RASSP,  the  assessment  of  the  analysis  results 
from  a  design  upgrade  trade  study  would  be  of 
use  to  several  people,  including  the  customer, 
program  management  and  the  system  developer. 
The  ability  to  view  assessment  data  in  a  form  that 
is  meaningful  and  allows  for  a  quick 
interpretation  of  the  results  would  be  imponant. 
Figure  3.1-12  shows  an  example  of  two  different 
abstract  views  on  a  Life  Cycle  Cost  (LCC) 
spreadsheet.  In  an  LCC  spreadsheet  there  are 
multiple  relating  parameters.  A  change  in  any 
one  variable  has  the  potential  of  producing 
multiple  changes  throughout  the  spreadsheet. 

This  example  shows  the  LCC  spreadsheet 
represented  as: 

VIEWl  -  LCC  subsystem  percentage  cost 

VIEW2  -  subsystem  cost  vs.  system  on  time 

In  addition  to  the  virtual  reality  research 
underway  at  the  University  of  San  Francisco, 
there  is  also  work  on  Virtual  Reality  and 
Synthetic  Environments  at  Washington 
University.  Also,  companies  have  begun  to  use 
visualization  techniques  within  their  current 
product  line.  An  example  is  Mentor  Graphics' 
Decision  Support  System  (DSS)  product. 

3. 1.2.3  Product  Design  Concurrent 

Engineering  Environment 

During  the  RASSP  Study  Phase,  the  team 
researched  applicable  CAE  tools  and  methods 


(commercially-available,  advanced  research,  and 
applicable  DoD  initiatives).  Some  of  the  tools 
already  rely  on  the  use  of  standards  (for  input 
rrxxleling  and  use  of  libraries)  within  their  current 
tools.  To  realize  RASSP  goals,  the  block  one 
RASSP  Design  System  will  take  advantage  of 
tools  and  concepts  that  use  advanced  techniques 
so  that  integration  is  easier  and  the  proof-of- 
principle  can  be  completed  within  the  first  year  of 
the  RASSP  program.  The  following  are  the 
important  criteria  that  will  be  followed  when 
choosing  CAE  tools  to  integrate  for  the  block  one 
design  system: 

•  Functionality 

•  Use  of  modeling  standards  (VHDL,  Ada, 
Verilog,  etc.)  for  input  and  output 
mechanisms 

•  Integration  of  CAE  tool  with  standard 
libraries  of  COTS  parts 

•  Ease  of  Use 

•  Open  architecture 

•  Link  to  other  CAE  tools 

Table  3.1 -13a  highlights  the  criteria  and  gives  an 
example  set  of  system  engineering  tools  that  are 
moving  in  the  direction  necessary  for  RASSP 
goals.  The  table  does  not  go  into  detail  for 
software,  hardware  and  physical  design  phases 
of  the  system  design  life  cycle.  Tools  used  by 
designers  in  these  phases  are  well  established, 
integrated  to  a  large  extent,  and  taking  advantage 
of  current  modeling  standards  and  libraries. 
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Framework  (and 

U/I  models 

Design  Aut. 

-  University  of 
Virginia  U^ 

VHDL 

Performance 

models 

models 

suite  of  CAE 
tools) 

-  Racal-Redac 
Framework  (and 
suite  of  CAE 
tools) 

-  ADAS  to 
Teamwork 

-  IDAS  to 
Synopsys 

-  SES  Workbench 
to  Software  thru 
Pictures 

TABLE  3J-13A,  EXAMPLE  SET  OF  SYSTEM  ENGINEERING  CAE  TOOLS 
CURRENTLY  MEETING  RASSP  DESIGN  SYSTEM  CRITERIA 


This  table  provides  an  example  set  of  tools  that 
are  currently  conforming  to  one  or  more  of  the 
criteria  elements  described  above  and  therefore 
can  be  integrated  successfully  into  the  block  one 
RASSP  Design  System  release  within  the  first 
year  of  the  program.  However,  in  order  for 


RASSP  to  be  successful,  several  other  design 
system  elements  are  important  for  meeting 
RASSP  goals.  A  list  of  important  design  system 
elements  follows  along  with  the  expectations  for 
which  of  these  elements  are  being  addressed  by 
industry  within  the  time  frame  of  this  program. 
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•  CFI  Program:  EDA  and  Manufacturing 
Integration  will  be  completed  within  the 
RASSP  program  time  frame  regardless  of 
additional  RASSP  funding.  The  RASSP 
program  should  provide  direct  funding  to 
CFI  for  any  additional  integration  strategies 
such  as  CASE/  Codesign  Integration  and 
Enterprise  Integration. 

•  MHDL.  AHDL.  VHDL  Programs:  VHDL  is 
continuing  to  proceed  and  will  do  so 
regardless  of  additional  RASSP  funding. 
However,  the  RASSP  program  should 
provide  input  to  and  a  strong  presence  with 
the  standards  bodies  to  ensure  success.  The 
definition  of  AHDL  is  slower  in  proceeding 
but  will  be  defined  within  the  RASSP 
program  time  frame.  The  MHDL  program, 
under  Intermetrics,  is  still  in  its  early  stages 
and  will  need  to  be  monitored  to  determine  its 
RASSP  potential. 

•  Generic  System  Description  Language:  • 
There  exists  the  need  to  develop  a  standard 
representation  for  system  models  that  can  be 
used  prior  to  partitioning  a  system  into 
digital,  analog,  microwave,  and  software 
subsystems.  There  is  currently  no  standards 
or  industry  organization  addressing  this 
issue.  It  is  important  for  RASSP  goals  and 
should  be  an  area  of  investment  for  RASSP. 

•  Library  Standardization:  Developing 
standard  library  representations  for 
performance  models,  functional  models, 
reliability  models,  manufacturing  process 
models,  etc.  is  an  area  that  the  RASSP 
program  should  consider  as  an  investment 
area. 

•  Database  Integration  Techniques:  The 
industry  move  towards  integrated  databases 
rather  than  the  replacement  of  existing 
databases  is  emerging  with  various  data 
dictionary  techniques  that  use  metadata  to 
describe  the  relationships  between  existing 


databases.  Tools,  such  as  those  under 
development  by  Xerox,  are  moving  forward 
and  should  be  available  for  use  on  the 
RASSP  program. 

•  Availability  of  engineering  estimate  models 
for  design,  logistics  and  manufacturing  data: 
The  Raytheon  RASSP  Design  System 
concept  relies  on  the  existence  of  models  at 
various  levels  of  abstraction  in  order  to 
assess  the  cost,  risk  and  benefit  of  design 
upgrades  and  in  order  to  design  for  model 
year.  Ensuring  that  these  models  are 
available  should  be  a  consideration  and  a 
possible  RASSP  investment  area. 

•  Development  of  CAE  tools  which  provide  the 
following  functionality:  This  functionality  is 
necessary  for  the  RASSP  program  and  it 
should  be  a  possible  RASSP  investment  area. 

•  Early  assessments  based  on  engineering 
estimate  data 

•  Hardware/  Software  codesign  tools 

•  System  and  subsystem  functional 
partitioning/high-level  synthesis  tools 

•  System-Level  manufacturing  advisor 

•  System-Level  logistics  advisor 

•  System-Level  packaging  compiler 

•  Behavioral  mixed-mode  simulation 
(Behavioral  VHDL  co-simulated  with 
Behavioral  MHDL) 

•  System-Level  Testability  Advisor/  BIT 
Insertion 

Under  the  product  design  concurrent  engineering 
environment,  the  product  design  activities  are  as 
follows: 

•  Requirements  design  and  analysis 

•  Concept  (preliminary)  design  and 
analysis 

•  Software  design  and  analysis 

•  Hardware  design  and  analysis 

•  Physical  design  and  analysis 

In  keeping  with  the  concurrent  engineering 
philosophy,  these  product  design  activities  work 
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in  parallel  and  do  not  necessarily  need 
information  from  one  phase  in  order  to  complete 
work  in  another  phase  (although  that  paradigm 
will  work  also). 

Each  of  these  phases  breaks  down  into  the  major 
activities  performed  under  the  phase.  For 
example,  under  the  requirements  design  and 
analysis  phase,  the  four  major  activities 
performed  are: 

1 .  Requirements  Developnvent 

2.  Requirements  Analysis 

3.  Requirements  Traceability 

4.  Requirements  Documentation 

Under  the  study  phase,  the  Raytheon  team 
researched  the  state-of-the-art  CAE  tools 
(commercially  available  and  public  domain), 
applicable  research  efforts,  and  applicable  DoD 
programs  available  for  each  activity. 
Additionally,  we  researched  the  advanced  ideas 
and  methods  for  those  areas.  The  following 
subsections  break  down  each  of  those  phases 
into  the  major  activities,  provides  a  matrix  chart 
detailing  a  subset  of  State-Of-The-Art  (SOTA) 
and  advanced  research  tools  and  methods  for 
those  activities.  Additionally,  a  detailed  table  is 
included  that  details  all  tools  and  methods 
identified  and  researched  as  applicable  under  the 
RASSP  study  phase. 


Table  3.1-15  gives  details  for  each  of  the  tools 
researched.  A  brief  overview  of  the  pros  and 
cons  found  during  our  study  for  a  sample  set  of 
tools  follows: 


State-of-the-Art 


Tools  Dev.  Anal.  Trace  Doc 


VHDL 

✓ 

✓ 

✓ 

Statemate 

✓ 

✓ 

RDD 

✓ 

✓ 

✓ 

TAGS 

✓ 

✓ 

Product  Track 

✓ 

Rtrace 

✓ 

✓ 

TABLE  3.1-13B,  EXAMPLE  SET  OF 
STATE-OF-THE-ART  CAE  TOOLS  FOR 
THE  SYSTEM  LEVEL  REQUIREMENTS 
ANALYSIS  PHASE 


Advanced  Research 


Tools  Dev.  Anal.  Trace  Doc 


Syat.  Daa.  Station 

✓ 

✓ 

-7 - 

✓ 

Redwood  Dee.  Aut 

✓ 

✓ 

✓ 

Martin  Marietta  RM 

✓ 

✓ 

HRL  RAPIDWS 

✓ 

✓ 

✓ 

V 

3. 1 .2.3. 1  Requirements  Design  and 
Analysis  Phase 

The  main  activities  in  system  requirements  design 
and  analysis  are: 

1)  Requirements  Development  (Dev.) 

2)  Requirements  Analysis  (Anal.) 

3)  Requirements  Traceability  (Trace) 

4)  Requirements  Documentation  (Doc.) 

Tables  3.1-13  ..nd  3. 1 .- 14  represent  a  subset  of 
the  tools  (both  current  state-of-the-art  and 
advanced  research)  that  address  the  system 
requirements  design  and  analysis  activities. 


TABLE  3.1-14,  EXAMPLE  SET  OF 
ADVANCED  RESEARCH  CAE  TOOLS 
AND  METHODS  FOR  THE  SYSTEM 
LEVEL  REQUIREMENTS  ANALYSIS 
PHASE 

The  VHDL  (VHSIC  Hardware  Descriptive 
Language)  standard  is  used  to  develop,  analyze, 
and  document  system  requirements  and  design. 
The  VHDL  standards  committee  has  continued  to 
advance  the  standard  language  with  features 
necessary  for  it  to  be  the  complete  top-down 
design  and  documentation  language  for 
electronics.  Through  design  and  development  of 
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the  RASSP  Design  System,  the  RASSP  team 
will  identify  any  features  missing  or  incomplete 
in  VHDL  and  will  work  with  the  standards 
organization  to  address  the  issues. 

The  Statemate  tool,  from  i-Logix,  Inc.,  is  used  to 
graphically  develop  and  analyze  system 
requirements.  Statemate  requires  proprietary 
graphical  languages  as  input  and  will  not  accept 
input  from  any  other  graphical  or  textual 
environment.  Statemate  outputs  C,  Ada,  VHDL, 
MIL-STD  2 167  A  (and  user-defined) 
documentation.  The  current  version  of 
Statemate  does  not  allow  the  use  of  parameterized 
library  models.  It  has  been  used  at  Raytheon  for 
developing  and  analyzing  system,  software  and 
digital  hardware  requirements. 

The  Product  Track  tool,  from  Cimflex 
Technologies,  was  originally  developed  under 


DARPA  DICE  funding  (originally  called 
Requirements  Manager).  It  gives  the  user  the 
ability  to  track  requirements  throughout  the 
design  process.  It  does  not,  however, 
automatically  link  from  the  allocated  requirements 
to  the  appropriate  design  documents,  design 
models  and  design  rationale  that  support  those 
requirements.  If  a  requirement  changes,  updates 
must  be  tracked  manually  to  assure 
synchronization. 

A  new,  as  yet  unreleased,  tool  from  Redwood 
Design  Automation  provides  the  capabilities  of 
developing,  analyzing,  and  documenting 
requirements.  It  will  provide  both  a  VHDL  &  a 
Verilog  input  and  output  mechanism.  It  will 
support  library  models. 
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001  Name  Company  Function 
Name 


eqts.  L>esign 
:  Analysis 


Various 
VHDL 
simulators 


nput  Output 

Formats  Formats 


Ascent  Logic 
Corp. 


Teledyne 
Brown  Eng. 


Various 

Vendors 


Redwood 

Design 

Automation 


eqts.  Design 
;  Analysis 


eqts.  Design 
:  Analysis  I  Verilog 


eleased 
Unreleased 


mmercial  !  Released 


ystem  Mentor 

Design  Graphics 

Station 


Rtrace 


Product 

Track 


Raytracer  Raytheon 


Verilog 


Mentor 
Proprietary 
Graphical 
Languages  & 
VHDL 


Reqts./ 

Documents 


VHDL 
simulation 
model  VHDL 
doc. 


VHDL 
Verilog 


VHDL,  links 
to  CASE 
tools 


Reqts. 

Matrix 


Reqts. 

Matrix 


Reqts. 

Matrix 


Reqts. 

Matrix 


mmercial  i  Released 


mmercial  1  Released 


mmercial  Released 


mmercial  I  Unreleased 


mmercial  1  Unreleased 


mmercial  1  Released 


mmercial  Released 


Reqts./ 

Documents 


Reqts. 

Matrix 


Martin 

Marietta 

IR&D 


Released 


Umeleased 


Released 


TABLE  3.1-15,  DETAILED  INFORMATION  ON  THE  SYSTEM  LEVEL 
REQUIREMENTS  ANALYSIS  TOOLS  RESEARCHED 
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3.1.2.3.2  Concept  (Preliminary)  Design  and 
Analysis  Phase 

The  main  activities  in  concept  design  and  analysis 
are: 

1)  Concept  Development  (CD) 

2)  Functional  Analysis  (F) 

3)  Performance  Analysis  (P) 

4)  Testability  Analysis  (T) 

5)  Manufacturability  Analysis 

6)  Reliability/  Safety  Analysis  ^R/S) 

7)  Functional  Partitioning  (FP) 

8)  High-Level  Synthesis  (S) 

9)  HW/SW  Co-design  (C) 

Tables  3.1-16  and  3.1-17  represent  a  subset  of 
the  tools  (both  current  state-of-the-art  and 
advanced  research)  that  address  the  concept 
design  and  analysis  activities.  Included  in  this 
section  is  a  brief  overview  of  the  pros  and  cons 
found  during  our  study  for  a  sample  set  of  tools. 
Additionally,  Table  3.1-18  gives  details  for  each 
of  the  tools  researched  in  our  study. 

Staf-of-the-An 

Tools  CD  F  P  T  M  R/S  FP  S  C 


VHOL 

✓ 

✓ 

IDAS 

✓ 

✓ 

✓ 

✓ 

✓ 

StaWmai* 

✓ 

✓ 

✓ 

✓ 

✓ 

SES  Workbanch 

✓ 

✓ 

ADAS/  Taamworfc 

✓ 

✓ 

✓ 

HARP 

✓ 

✓ 

STAT 

✓ 

✓ 

TABLE  3.1’16,  EXAMPLE  SET  OF 
STATE-OF-THE-ART  CAE  TOOLS  FOR 
THE  CONCEPT  DESIGN  AND 
ANALYSIS  PHASE 

The  IDAS  tool,  from  JRS  Research,  Inc.,  allows 
the  user  to  design  and  analyze  processors, 
software,  and  pre-processing  hardware  for 
embedded  processing  systems  concurrently.  The 
tool  inputs  an  Ada  algorithm  and  a  subset  of 
VHDL,  generates  microcode  to  run  on  the  target 
architecture,  and  evaluates  the  performance  of  the 
embedded  processing  system  through  simulation. 
Under  the  DARPA  DICE  initiative,  the  IDAS  tool 
is  being  enhanced  to  include  additional  hardware 


entities,  architectural  rules  and  to  accept  multiple 
behavioral  specifications. 


Advanced  Research 

Toole  CDFPTMRy^FPSC 


MCC  TMtability 
Acivltor 

✓ 

✓ 

UVA  U/1  VHOL 

Modala 

✓ 

✓ 

✓ 

✓ 

✓ 

DICE  Uan.  OpL 

✓ 

Univarslly  of 

✓ 

✓ 

TABLE  3.I.-I7,  EXAMPLE  SET  OF 
ADVANCED  RESEARCH  CAE  TOOLS 
AND  METHODS  FOR  THE  CONCEPT 
DESIGN  AND  ANALYSIS  PHASE 

The  SES  Workbench  tool,  from  Scientific  and 
Engineering  Software,  Inc.,  provides  the  user 
with  a  proprietary  graphical  input  format  to 
analyze  the  performance  of  the  system  concept. 
The  tool  provides  a  link  to  the  CASE  tool  from 
IDE  called  Software  Through  Pictures.  This 
allows  the  user  to  develop  software  functional 
requirements  and  manually  analyze  them  for 
conformance  to  the  performance  requirements 
defined  in  SES  Workbench. 

The  University  of  Virginia  is  researching  the 
applicability  of  using  VHDL  to  model  and 
analyze  the  system  concept  for  conformance  to 
functional,  performance,  reliability,  and 
operational  concept  requirements.  In  addition, 
UVA  is  looking  at  VHDL  as  an  environment  for 
hardware  and  software  codesign.  UVA  has 
defined  a  set  of  primitive  VHDL  models  that  can 
be  used  to  create  the  simulation  models. 

To  realize  model  year  objectives,  RASSP 
designers  must  have  tools  available  to  analyze  the 
producibility/  manufacturability  of  the  design  at 
an  early  point  in  the  design  cycle.  Current  and 
future  information  regarding  the  vendor  base 
capabilities,  costs,  availability,  etc.  must  be 
analyzed.  Under  the  DARPA  DICE  program, 
Raytheon's  Manufacturing  Optimization  program 
is  bringing  manufacturing  information  to  module 
designers  during  the  design  process.  These 
capabilities  must  be  extended  to  the  system 
designers  under  the  RASSP  Design  System. 
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TABLE  3.1-18,  DETAILED  INFORMATION  ON  THE  CONCEPT  DESIGN  AND 

ANALYSIS  TOOLS  RESEARCHED 


ool  Name 


unction 


tatemate 


i-Logix,  Inc.  Performance 
Analysis 


AD 
Teamwork 


Research 

Triangle 

Institute/ 

Cadre 


MetaSo 


Performance  Petri  Nets 
Analysis 
linked  to 
S/W  Reqts. 

Etesign  Tool 


Performance 

Models 


VHDL  Honeywell 

Performance 

Models 


nput  Output 
Formats  Formats 


Performance 
statistics,  C, 
Ada,  VHi)L, 
2 167 A  doc. 


Performance 

Statistics/ 

Teamwork’s 

input 

language 

format/ 

VHDL 


Performance 

statistics 


Performance 

statistics 


Performance  VHDL 
Analysis 


Performance 

Analysis 


Workbench/ 

STP 


Performance 
Analysis  Proprietary 
Graphical 
Languages 


ID  Performance 

Technologies  Analysis 
,  Inc. 


Matrix-X 


Control  Matnx-X 

System  Proprietary 

Eiesign  and  Graphical 

Implementati  Languages 


eieased 
Unreleased 


Released 


ommercial  Released 


Research 


Performance  Honeywell 
statistics  IR&D 


Performance 

statistics 


Performance 
statistics/ 
STP's  input 
language 
format 


Performance 

Statistics 


FORTRAN 


Released 


Released 


Released 


Released 


Released 


Unreleased 
beta  product 
Q4,  1992 


ommercial  Released 


Released 
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I 

I 


"Sure 

Finite  State 

IlSISSi 

Public 

Domain 

Released 

Raytheon 

Subsystem  & 
Block  Failure 
Data 

System 

Reliability 

Raytheon 

IR&D 

Released 

FLEX 

Navy 

IIH 

Cost 

Analysis 

Data 

Public 

Domain 

Released 

Price 

LCC 

Cost 

Analysis 

Data 

Commercial 

Released 

■^TaT 

DETEX 
Systems  Inc. 

Testability 
Analysis  & 
Diagnostics 

STAT 
Proprietary 
format  for 
HAV  Block 
Diagram 

ASCn 
reports  & 
STAT 
proprietary 
format 

Commercial 

Released 

WSTA 

Harris 

Testability 
Analysis  & 
Diagnostics 

■ 

Asen 
reports  & 
WSTA 
proprietary 
format 

Navy 

Program 

Released 

IDAS 

Research 

Custom 

Processor 

Software 

synthesis 

Ada,  C, 
VHDL 

Microcode 
running  on 
target 

architecture, 
rapid  test 
results  of 
design 
alternatives 

Commercial 

Released 

Multi¬ 

component 

Synthesis 

Tools 

University  of 
Qncinnati, 
Michigan 
State, 

DASYS,  Inc. 

Multi¬ 

component 

Synthesis 

VHDL 

Partitioned 

MCM 

Wright 

Laboratories’ 

DoD 

program 

Unreleased 

Signal 

Processing 

Workstation 

Comdisco 

Systems, 

Inc. 

DSP  Design 
&  Analysis 

Proprietary 

Graphical 

Languages 

VHDL  that 

drives 

Synopsys 

synthesis 

tool 

Commercial 

Released 

DSP 

Mentor 

Graphics 

DSP  Design 
&  Analysis 

VHDL, 

MentOT 

Languages 

VHDL, 

silicon 

con^iler/ 

synthesis 

format 

■ 

Released 

Hypersignal 

Hypercepdon 

DSP  Design 
&  Analysis 

Text  displays 

Released 

HiTEA 

MCC 

Testability 

Advisor 

VHDL 

Research 

Released 
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3.1. 2.3.3  Software  Design  and  Analysis 

The  main  activities  in  software  design  and 
analysis  are: 

1 )  Software  Reqts  Development  (RD) 

2)  Preliminary  Design  (PD) 

3)  Detail  Design  Development  (DD) 

4)  Code  and  Unit  Test  (CUT) 

5)  Integration  and  Test  (IT) 

6)  Independent  Validation  &  Verification 
(IV&V) 

Table  3.1-19  represents  a  subset  of  the  tools  that 
address  the  software  design  and  analysis 
activities.  Table  3.1-20  gives  details  for  a  subset 
of  the  tools  researched.  Advanced  technologies 
that  should  be  leveraged  on  RASSP  are  being 
done  under  DARPA's  DSSA  (Domain  Specific 
Software  Architecture)  program,  SW 
Reusability,  and  Synthetic  Environments 
research. 


Tools  RD  iv&v 


STP 

✓ 

✓ 

Statamat* 

✓ 

✓ 

Intartaaf 

✓ 

✓ 

✓ 

Taamworli/SART 

✓ 

✓ 

Taamwork/Ada 

✓ 

Taamwork/DSE 

✓ 

Ada  CompUar 

✓ 

Static  Analyzar 

✓ 

Parformanca 

Analyzar 

✓ 

Covaraga  Anal. 

✓ 

Support  SW 

✓ 

Thread  Taating 

✓ 

Integration 

✓ 

Test  Bullda 

✓ 

TABLE  3.1 -19,  EXAMPLE  SET  OF 
STATE-OF-THE-ART  CASE  TOOLS 
FOR  THE  SOFTWARE  DESIGN  AND 
ANALYSIS  PHASE 


Tool  Name 

Company 

Name 

■ 

Input 

Formats 

Output 

Formats 

Released/ 
Ur  released 

Teamwork/ 

SART 

Cadre,  Inc. 

Cadre  Prop. 

Graphical 

Languages 

C,  Ada, 
2167Adoc. 

Commercial 

Released 

Teamwork/ 

Ada 

(Dadrc,  Inc. 

Objea- 

oriented 

design 

Cadre  Prop. 

Graphical 

Languages 

C,  Ada, 
2167A  doc. 

Ck)mmercial 

. 

Released 

Teamwork/ 

DSE 

Cladre,  Inc. 

Syntax 

E^tor 

Cadre  Prop. 

Graphical 

Languages 

C,  Ada, 
2167A  doc. 

Commercial 

Released 

TABLE  3.1-20,  DETAILED  INFORMATION  ON  A  SUBSET  OF  THE  SOFTWARE 
DESIGN  AND  ANALYSIS  TOOLS  RESEARCHED 
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3. 1.2, 3.4  Hardware  Desipn  and  Analysis 

The  main  activities  in  hardware  design  and 
analysis  are; 

1)  Simulation  (S) 

2)  Logical  Partitioning  (L) 

3)  Design  Capture  (D)  through  schematic 
capture  (Syn)  and  synthesis  (SC) 

4)  Emulation  (E) 

5)  Acceleration  (A) 

6)  H/W  Modeling  (M) 

7)  Tester) 

Tables  3.1-21  and  3.1-22  represent  a  subset  of 
the  tools  (both  current  state-of-the-art  and 
advanced  research)  that  address  the  hardware 
design  and  analysis  activities.  Table  3. 1.-23 
gives  details  for  each  of  the  tools  researched. 
Commercially-available  tools  under  this  design 
phase  have  been  user-hardened.  In  many  cases 
they  are  integrated  into  ffamewo*ft.s  and  should 
be  an  easy  integration  into  the  RASSP  Design 
System. 

Wright  Laboratories  currently  has  a  program 
called  Multicomponent  Synthesis  that  has  been 
awarded  to  University  of  Cincinnati,  Michigan 
State  and  DASYS,  Inc.  Under  this  contract, 
advanced  research  and  development  is  underway 
to  develop  high-level  partitioning  and  synthesis 
techniques  for  MCMs.  The  ideas  developed 
under  this  contract  will  be  watched  for  the 
possible  extension  to  partitioning  and  synthesis 
of  modules  and  subsystems. 


State-of-the-Art 


Tools  Sir  •'.ynSC  E  A  M 


VHDL  -  1076 

B 

VHOL  ■  XL 

RPM  Emul.  Sys. 

B 

✓ 

IKOS 

✓ 

Capfast 

B 

■ 

D 

■ 

D 

Synopaya 

■ 

B 

□ 

B 

■ 

Sptca 

B 

■ 

D 

■ 

■ 

■ 

LM  Modalara 

_ 

_ 

_ 

_ 

_ 

✓ 

TABLE  3.1-21,  EXAMPLE  SET  OF 
STATE-OF-THE-ART  CAE  TOOLS  FOR 
THE  HARDWARE  DESIGN  AND 
ANALYSIS  PHASE 


Advanced  Research 


Tools  S  L  D  Syn  SC  E  A  M 


DASYS,  Inc. 

n 

F 

✓ 

U.  of  Cincinnati 

✓ 

✓ 

✓ 

Michigan  St. 

✓ 

✓ 

TABLE  3.1-22,  EXAMPLE  SET  OF 
ADVANCED  RESEARCH  CAE  TOOLS 
AND  METHODS  FOR  THE  HARDWARE 
DESIGN  AND  ANALYSIS  PHASE 
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TABLE  3.1-23,  DETAILED  INFORMATION  ON  THE  HARDWARE  DESIGN  AND 

ANALYSIS  TOOLS  RESEARCHED 


Company 

Pool  Name  | 

Name 

VHDL-1 


VHDL-XL 


Cadence 


VHDL2 


Verilog 


i-Logix,  Inc.  Reqts. 

Design  & 
Analysis 


Behavioral 

Simulation 


Behavioral 

Simulation 


Behavioral 

Simulation 


Behavioral 

Simulation 


Behavioral 

Simulation 


ence  Simulator 


PiE  Inc.  I  Emulation 


RPM 

Emulation 

System 


QuickTum  Emulation 
Inc. 


Zycad 


IK 


Hardware 

accelerator 


Hardware 

accelerator 


LM-family  of  Logic  Hardware 

universal  Mc^eling  modeler 

modelers  Systems  Inc. 


npui  Output 

Formats  Formats 


VHDL 


VHDL 


VHDL 


VHDL 


VHDL 


VHDL 


Verilog 


imulation 
with  majOT  Reports 
ASIC 
vendors 
(Mentor, 

Cadence) 


EDIF/all 


major  ASIC  Reports 

vendor 

formats 


Interface  to 
all  major 
ASIC 
vendors 


Interface  to 
all  major 
ASIC 
vendors 


Simulation 

Reports 


Simulation 

Reports 


eleased 
Unreleased 


Commercial  i  Released 


Released 


Commercial  Released 


Released 


Commercial  Released 


Commercial  Released 


Released 


Commercial  |  Released 


Simulation  Commercial  Released 


Released 


Commercial  i  Released 


ommercial  Released 


ommeraal  Released 
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■ 

■ 

Schematic 
capture  for 
ICs 

Proprietary 

graphical 

language 

-wm - 

proprietary 
link  to  other 
Cadence 
tools 

Commercial 

Released 

Schematic 
capture  for 
boards 

^9 

Simulation 

Reports 

Commercial 

Released 

■ 

Phase  Three 
Logic  Inc. 

Schematic 
capture  for 
boards 

EDIF 

Commercial 

Released 

Logic 

Assistant 

Compass 

Design 

Automation 

Schematic 
capture  for 
ICs 

Proprietary 

graphical 

language 

EDIF; 
Proprietary 
links  to  other 
Compass 
tools 

Commercial 

Released 

Motive 

Quad  Design 
Technology 

Timing 

Analysis 

Netlist  & 
(Component 
timing  data 

Timing 

violation 

reports 

Commercial 

Released 

Design 

Compiler 

7SIC 

Synthesis 

Verilog; 

VHDL 

EDIF; 

schematic  for 
major  ASIC 
vendors 

Commercial 

_ 

Released 

mijm 

Mentor 

Graphics 

Static  timing 

VHDL, 

Mentor 

Languages 

Timing 
reports  & 
diagrams 

Released 

SilcSyn 

RacalRedac 

Design 

Systems 

aSIC 

Synthesis 

VHDL 

schematic  for 
major  ASIC 
vendors 

Commercial 

Released 

Autologic 

VHDL 

Released 

H— 

Various 

companies 

Analog 

Simulation 

Spice  netlist 

iSHI 

Released 

■ 

Integrated 

Circuits 

Applications 

(INCA) 

Emulation 

Interface 
with  major 
ASIC 
vendors 

Simulation 

reports 

Commercial 

Released 
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The  main  activities  in  physical  design  and 
analysis  are: 


1)  Place  and  Route  (PR)  of  MCMs  (M), 
Boards  (B)and  (Custom  devices  (C) 

2)  Verification  (V) 


Table  3.1-24  represents  a  subset  of  the  tools  that 
address  the  physical  design  and  analysis 
activities.  Table  3.1-25  gives  details  for  each  of 
the  tools  researched,  ^mmercially-available 
tools  under  this  design  phase  have  been  user- 
hardened  and  should  be  an  easy  integration  into 
the  RASSP  Design  System. 


TABLE  3.1-24,  EXAMPLE  SET  OF 
STATE-OF-THE-ART  CAE  TOOLS  FOR 
THE  PHYSICAL  DESIGN  AND 
ANALYSIS  PHASE 
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I 


Commercial!/ 
Research/ 
DoD  / 
IR&D 


Releasee 

llnreleasc. 


Tool  NamT 


Company 

Name 


Function 


Input 

Formats 


Output 

Formats 


(jDSU 


CommerdaT 


Visuia 


RacalRedac 

Inc. 


Board  Place 
and  Route 


Proprietary 
Input  format 


Released 


Commercial 


Board 

Station 


Mentor 

Graphics 


Board  Place 
and  Route 


Proprietary 
Input  format, 
VHDL, 

EDIF 


EDIF 


Released 


Cadence 


(jDSII 


Commercial 


Allegro 


Gate 

Ensemble 


Board  Place 
and  Route 


Proprietary 
Input  format, 
VHDL, 

EDIF 


Cadence 


Gate  Array 
Place  and 
Route 


Released 


GdSD; 

CIF 


CommerciaT 


Proprietary 
Input  format, 
EDIF 


Released 


Cdi 

Ensemble 


C^ence 


Standard  Cell 
Place  and 
Route 


Proprietary 
Input  format, 
EDIF 


GDSD; 

CIF 


Commercial 


Released 


Compass 

Design 

Automadon 


Commercial 


Gate 

Compiler 


Gate  Array 
Place  and 
Route 


ftopnetary 
Input  format, 
EDIF 


Released 


Compass 

Design 

Automation 

Cadence 


CeU 

Compiler 


Standard  Cell 
Place  and 
Route 


Proprietary 
Input  format, 
EDIF 
TSdSh 


Commercial 


Released 


Commercial 


DRACULA 


Checkmate 


Design 
verification 
ERC,  DRC, 
LVS 


vanous 

verification 

reports 


Released 


Design 
verification 
ERC,  DRC, 
LVS 


GdSii 


CommerciaT 


Mentor 

Graphics 


vanous 

verification 

reports 


Released 


TABLE  3.1-25,  DETAILED  INFORMATION  ON  THE  PHYSICAL  DESIGN  AND 

ANALYSIS  TOOLS  RESEARCHED 
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3.1.3  CALS  Interface 

The  DoD  has  become  very  concerned  with  the 
completeness  of  technical  data  packages,  the 
receipt  of  these  packages  in  a  paper  format,  and 
the  availability  of  the  data.  As  a  result,  the  CALS 
initiative  was  formulated  to  allow  the  electronic 
capture  and  delivery  of  the  technical  data  package 
in  a  standard  format.  In  addition,  the  DOD 
would  like  access  to  the  technical  data  during  the 
development  phase  of  a  program,  as  defined  in 
MIL-C-CmS  (Contractor  Integrated  Technical 
Information  Service),  rather  than  only  at  the 
program's  completion.  As  a  result  of  these 
requirements,  there  exists  accepted  standards  for 
the  delivery  of  graphical  data,  such  as  schematics 
and  board  layouts  in  MIL-M-28001A  compliant 
standards,  the  delivery  of  documentation  in 
SGML  format,  and  the  delivery  of  VHDL 
models.  One  of  the  difficulties  with  the  current 
standards  is  that  the  schematic  and  board  layout 
data  is  generally  delivered  as  a  raster  format, 
rather  than  IGES.  The  principal  reason  for  this  is 
the  problem  with  CAD  systems  being  able  to  read 
each  others  IGES.  The  intent  is  that  the  CALS 
deliverable  data  be  in  a  format  which  will  allow 
interchange  of  the  data  with  other  CAD  systems 
and  support  the  acquisition  process.  To  achieve 
this  objective,  improvements  to  the  delivery 
standards  such  as  EDIF  2.0  for  schematics,  for 
PCB  view  and  for  test  vectors,  which  are  due  to 
be  released  in  1993,  and  STEP  for  the  product 
data  are  required.  Under  the  RASSP  program,  it 
is  imperative  that  the  technical  information 
package  be  automatically  derived  from  the  CAD 
framework,  and  support  the  current,  as  well  as 
the  emerging  standtu’ds,  for  CALS  compliance. 

In  order  to  accomplish  the  above  goals,  RASSP 
should  maintain  contact  with  the  CALS  Industry 
Working  Group  (IWG)  to  support  the 
requirements  for  DOD  access  to  the  design  data, 
as  well  as  involvement  in  the  PAP-E/STEP 
program  to  assure  that  the  CAD  framework 
supports  the  emerging  standards.  Work  should 
also  address  the  generation  of  SGML  compliant 
data  from  the  electronic  notebook  application,  as 


well  as  other  required  textual  deliverable  elements 
in  the  technical  data  package. 

A  major  benefit  that  the  RASSP  program  can 
provide  is  a  test  bed  for  the  emerging  CALS 
standards.  A  major  improvement  in  the  current 
CFI  standards  development  activity  is  the 
implementation  of  the  standard  in  a  pilot  program 
after  the  draft  has  been  issued,  and  prior  to 
voting  on  the  standard.  This  methodology 
allows  for  the  exercise  of  the  standard  and  the 
resolution  of  problems  prior  to  the  adoption  of 
the  standard.  In  this  way,  the  release  standards 
are  more  robust  and  complete. 

3.1.4  Design  System  Issues 

Design  standards,  such  as  VHDL,  provide  good 
candidates  for  the  design  and  documentation 
description  language  for  use  in  the  RASSP  model 
year  concept.  VHDL  is  a  technology  and  process 
independent  language  used  in  design  to  define 
and  document  an  electronic  system.  However, 
due  to  the  flexibility  of  the  language,  standards 
must  be  refined  before  the  RASSP  system  can 
maximize  the  effectiveness  of  VHDL 

The  VHDL  standards  committee  has  not 
completed  the  definition  of  the  VHDL  standard 
for  1992.  As  with  any  IEEE  standard,  IEEE- 
1076  must  be  reaffirmed  at  least  every  5  years. 
The  VHDL  Analysis  and  Standardization  Group 
(VASG)  has  reviewed  more  than  250  change 
requests  submitted  by  users  of  VHDL.  VASG 
decided  not  to  radically  change  the  language 
during  this  restandardization  period  due  to  the 
acceptance  VHDL  has  recently  gained  by  the 
commercial  vendors.  The  changes  to  the 
language  are  minimal  and  address  the  semantics 
of  the  language  and  additional  language 
constructs.  The  reaffirmation  of  IEEE  1076  is 
currently  in  the  balloting  phase. 

A  number  of  important  areas  were  not  included  in 
the  1992  restandardization.  The  VASG  elected  to 
have  these  areas  studied  further.  Table  3.1-26 
represents  the  standards  activities  currently  being 
addressed  that  have  an  impact  on  the  RASSP 
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program.  These  standards  are  currently 
incomplete.  The  RASSP  program  must  monitor 
each  of  these  standards  areas  closely  and 
influence  the  direction  of  the  standard  by  being  a 
member  of  the  committee  to  ensure  the  RASSP 
needs  are  met.  Those  standards  area  that  have  a 
direct  impact  on  RASSP  are  discussed  further  in 
the  following  sections. 

Detailed  timing  is  critical  to  the  successful 
development  of  a  high  performance  system.  A 
VHDL  model  must  be  developed  to  support 
minimum,  typical,  and  maximum  timing  and 
support  derating  factors  such  as  temperature, 
process,  and  voltage  variations.  Currently 
vendors  are  supporting  back  annotation  outside 
the  VHDL  model  through  their  simulator 
interface  since  it  is  extremely  difficult  to  do  this 
through  the  model.  A  standard  way  to  represent 
timing  and  a  standard  way  to  back  annotate  to  a 
VHDL  model  is  very  important  to  the  RASSP 
program.  A  study  group  for  VHDL  timing  and 
back  annotation  has  been  set  up  by  the  IEEE 
Computer  Society  Design  Automation  Standards 
Society  (DASS).  The  purpose  of  this  group  is 
to  develop  standard  methods  for  representing 
timing  related  information  for  use  in  VHDL 
models,  and  standard  modeling  practices  for 


making  use  of  this  information  in  a  consistent, 
simulator  independent  manner.  The  RASSP 
program  must  influence  this  group  to  make  sure 
its  needs  are  addressed. 

A  standard  package  for  synthesis  is  required  by 
the  RASSP  program.  The  synthesis  tools  in  use 
today  all  accept  only  a  subset  of  the  VHDL 
language  for  synthesis.  Each  vendor  happens  to 
accept  a  different  subset.  Additionally,  the  style 
that  is  used  in  writing  the  VHDL  will  produce 
different  results  depending  on  the  synthesis  tool 
used.  The  RASSP  concept  calls  for  reusable 
models  that  can  be  synthesized  to  generate  a  part 
on  demand  by  a  qualified  line.  What  is  required 
is  a  defined  subset  for  synthesis.  The  VHDL 
Synthesis  Package  Study  Group  is  an  IEEE 
committee  working  on  a  standard  package  to 
make  synthesis  from  VHDL  uniform  across 
vendors.  The  RASSP  program  must  follow  this 
effort  and  make  sure  the  package  is  defined  and 
influence  the  synthesis  vendors  to  adopt  the 
package. 

VHDL  supports  a  basic  set  of  arithmetic 
functions  for  integer  and  real  types.  The 
algorithmic  development  of  systems  requires 
higher  level  mathematical  functions.  The  VHDL 
Math  Package  Study  group  is  studying  the  best 


Standards  Area 

ii  IHif  H  M 

Timing  and  Back  Annotation 

Standi  Packages 

VHDL  Math  Package  Study  Group 

VHDL  Synthesis  Package  Study  Group 

VHDL  Analog  Extensions  Study  Group 

VHDL  Modeling  Practices,  PAR  1 164 

Information  Modeling 

Working  group  on  Information  Modeling, 
PAR  1078 

Interoperability 

VHDL  -  EDIF  Interoperability  Group,  PAR 
1165 

Intermediate  Forms 

VHDL  Intermediate  Form  Analysis  and 
Standardization  Group,  PAR  1163 

System  Design 

Working  Group  on  System  Design 
Languages 

Test 

DASS/SCC20  Test  Standards,  PAR 
1029.x,  TASG 

TABLE  3.I.-26,  VHDL  STANDARDS  STUDY  AREAS 


41 


UNCLASSIFIED 


way  to  implement  a  standard  math  package  in 
VHDL. 

Analog  modeling  in  VHDL  can  be  accomplished 
since  VHDL  is  such  a  heavily  typed  language, 
however  it  is  very  cumbersome  for  the 
developer.  The  VHDL  Analog  Extensions  Study 
group  is  studying  the  best  mechanisms  to 
implement  greater  analog  modeling  capability  into 
VHDL. 

The  following  areas  are  important  to  the  RASSP 
Design  System  but  are  currently  not  being 
addressed  under  the  VHDL  standards 
organizations.  The  RASSP  program  should 
influence  these  efforts,  however,  it  is  unlikely 
that  the  time  frame  for  developing  and  gaining 
agreement  on  these  standards  will  coincide  with 
the  RASSP  Design  System  need. 

Signal  processors  contain  both  analog  and  digital 
elements.  In  order  to  truly  model  the  system  in  a 
hardware  description  language  the  language  must 
suppon  both  analog  and  digital  components  and 
the  interaction  between  the  devices.  In  addition, 
a  simulation  environment  must  be  available  to 
accurately  and  correctly  simulate  the  mixed  mode 
model  at  various  levels  of  abstraction.  Mixed 
mode  simulation  must  address  issues  of 
synchronization,  signal  representation  and 
mapping,  and  partitioning. 

Object-oriented  VHDL  is  required  when  a  VHDL 
system  model  is  developed  to  model  both 
hardware  and  software  in  VHDL.  As  more 
software  development  activities  are  moving 
towards  object-oriented  languages,  VHDL  will 
be  most  effective  if  it  can  map  directly  into  the 
software  object-oriented  constructs. 

Library  standards  are  currently  being  developed 
for  logic  synthesis  and  math  functions.  CFI, 
under  the  CIR  subcommittee,  is  looking  at  the 
standardization  of  component  libraries  which 
should  set  the  stage  for  the  development  of 
standards  for  modeling  components  in  VHDL. 
Standards  for  other  library  models,  such  as 
standards  for  performance  models,  have  not  been 
addressed  under  any  standards  group.  The 


University  of  Virginia  has  done  extensive 
research  into  the  development  of  performance 
model  primitives.  Certainly,  UVA's  work 
should  be  a  starting  point  for  the  standardization 
effort. 

VHDL  is  gaining  acceptance  in  the  commercial 
marketplace.  Many  products  are  available  that 
either  input  or  output  VHDL.  The  problem  is 
many  tools  accept  or  generate  only  a  subset  of  the 
language.  In  the  seamless  RASSP  Design 
System  it  is  essential  that  VHDL  be  used  by  the 
many  tools  in  the  system  without  manual 
intervention  to  resolve  unsupponed  language 
constraints.  VHDL  automatically  generated  by 
these  tools  is  not  easily  read. 

The  CAD  Framework  Initiative  (CFI)  compliance 
standards  have  not  been  fully  defined.  Major 
CAD  vendors  such  as  Mentor  Graphics  and 
C^ence  have  developed  and  are  marketing  their 
own  frameworks.  Resolution  requires 
compromise. 

The  abstract  nature  of  model  representations 
complicates  the  translation  and  verification  of 
models  passed  between  CAE  tools.  CAE  tools 
use  models  that  support  the  function  provided  by 
that  tool.  For  example,  there  are  unique  models 
for  performance,  cost,  reliability,  testability,  and 
functionality.  There  is  no  means  to  verify  that 
the  models  represent  the  same  system.  The 
accuracy  and  validation  of  these  abstract  models 
is  critical  to  the  success  of  the  RASSP  design 
system. 

The  following  list  identifies  functional  areas  in 
the  RASSP  design  system  where  commercially 
available  CAE  tools  are  not  available  or  are 
incomplete  and  could  be  potential  RASSP 
investments.  These  tools  should  use  a  VHDL 
model  as  input 

1 .  Hardware  /  Software  codesign  tool 

2 .  System  Functional  partitioning/  High- 
level  synthesis  tool 

3.  System-level  manufacturing  advisor 

4.  System- level  logistics  advisor 

5 .  System-level  packaging  compiler 
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6 .  System-Level  Testability  Advisor/  BIT 
Insertion 

7 .  Behavioral  mixed-mode  simulators 

3.1.5  Raytheon  Related  Efforts 

Raytheon  has  been  active  in  the  development  of 
integrated  design  environments.  A  few  years 
ago,  Raytheon  implemented  a  prototype  "System 
Design  Environment"  shown  in  Figure  3.1-27. 
The  specification  of  the  system  was  captured 
using  i-Logix's  Statemate  product.  The 
Statemate  model  was  convened  to  a  VHDL 
behavioral  model  for  further  analysis.  The 
results  of  this  activity  were  presented  at  the 
VHDL  Intematitmal  User's  Meeting  in  two  parts: 
1)  "VHDL  -  Transition  from  System  to  Detailed 
Design"  presented  in  the  Spring  of  '90,  2)  "The 
Use  of  VHDL  from  System  To  Chip"  presented 
in  the  Fall  of  '90. 

Raytheon  also  demonstrated  a  seamless  VHDL 
based  design  environment  for  the  design  of 


digital  sub-systems.  In  this  effort,  Raytheon 
developed  a  model  of  a  sub-system  using  the  i- 
Logix  Express  V-HDL  product,  and  synthesized 
the  nx)del  into  a  gate  array.  The  model  was  also 
synthesized  into  an  FPGA  system.  Table  3.1-28 
lists  the  tools  used  or  evaluated  as  part  of  this 
demonstration.  Results  of  this  activity  were 
presented  at  the  VHDL  International  User's 
Meeting.  The  paper  was  entitled  "From 
Statecharts  to  Hardware  FPGA  and  ASIC 
Synthesis"  and  was  presented  in  the  Spring  of 
'92. 

A  more  recent  system  modeling  activity 
performed  by  Raytheon  was  the  development  and 
application  of  a  system  re-engineering 
methodology  to  a  sub-system  of  the  PATRIOT 
radar.  Figure  3.1-29  illustrates  the  methodology. 
Under  this  methodology,  an  executable  Statemate 
model  of  the  sub-system  was  developed.  The 
model  was  validated  against  the  current  system 
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Vendor 

Tool 

Function 

i-Logix 

Express/VHDL 

System  Modeling 

SES 

Workbench 

Performance  Modeling 

Mentor 

Silicon  Compiler 

Synthesis 

Vantage 

Spreadsheet 

Simulation 

DCOS 

Simulation  acceleration 

SYNOPSYS 

Design  Compiler 

Gate  level  synthesis 

XILINX 

FPGA  synthesis 

TABLE  3.1-28,  TOOLS  USED  AND  EVALUATED  FOR 
SEAMLESS  DIGITAL  DESIGN  ENVIRONMENT 


test  data.  In  this  way,  the  completeness  and 
accuracy  of  the  model  was  verified.  As  seen  in 
Figure  3.1-29,  many  sources  of  information 
were  utilized  to  develop  the  model.  Information 
was  not  limited  to  functionality  but  also  included 
performance  data.  This  model  now  serves  as  a 
complete  description  of  the  system  and  can  be 
used  to  developed  an  implementation  as  well  as 
providing  the  verification  data  to  insure  the  re¬ 
engineered  system  matches  the  original  system. 


Another  Raytheon  program 
aimed  an  integrating  tools 
for  concurrent  engineering 
was  the  RAPIDS  project, 
shown  in  Figure  3.1-30. 
This  system  integrated 
schematic  capture,  physical 
layout,  manufacturability 
analysis,  thermal  analysis, 
and  created  an  electronic 
database  which  was 
transferred  to  Raytheon's 
manufacturing  facilities  for 
fabrication.  This  system  is  currently  used  by  a 
number  of  Raytheon  engineering  sites  today. 


Figure  3.1-29,  System  Re-Engineering  Methodology 
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Tools 


PWB  Routing  Systems 


Figure  3.1 -30,  RAPIDS  Concurrent  Engineering  for  PWBs 


Raytheon  recently  proposed  a  "System  Re¬ 
engineering  System"  under  DICE  V.  This 
system  is  currently  under  review  by  DARPA. 
The  proposed  integrated  tool  set  (shown  in 
Figure  3.1-31)  for  concurrent  re-engineering  will 
improve  a  designer's  ability  to  capture  design 
intent  and  model  it  to  verify  adherence  to  current 
test  beds  prior  to  re-designing  the  system.  The 
objective  of  this  approach  is  to  ensure  that  the 


requirement  of  the  system  being  re-designed  are 
complete  and  model  the  existing  system.  The 
system  will  include  the  following  DICE  tools: 
Requirements  Manager  (RM),  Electronic  Design 
Notebook  (EDN),  Project  Coordination 
Board/Communication  Manager  (PCB/CM), 
Statemate  from  i-Logix,  and  HARP  for  fault 
tolerant  reliability  analysis.  Figure  3.1-32 
illustrates  the  system  information  flow. 
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Digital  Design 
Team  Member 


Reliability  Team 
Member 


Software  Design 
Team  Member 


System  Design 
Team  Member 


I 


Manufacturing  & 
Test  Team 
Member 


System  Reengineering  Workstation 
User  Interface 


Project 

Lead 

Engineer 


Project  Lead 
Engineer  User 
Interface 


Figure  3.1-31,  System  Re-engineering  Workstation  Environment 


Figure  3.1-32,  System  Re-engineering 
Workstation  Information  Flow 


Raytheon  has  won  one  of  the  DoD  Tri-Service 
MMACE  programs  to  develop  a  computational 
framework  for  the  design  and  manufacture  of 
microwave  and  millimeter- wave  tubes.  The 
conceptual  model  of  the  MMACE  framework  is 
depicted  in  Figure  3.1-33.  This  program  is 
similar  to  the  RASSP  program  in  that  one  of  its 
goals  is  to  develop  an  integrated  concurrent 
design  environment 
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Figure  3.1-33,  High  Level  Overview  of  the  MMACE  System 


The  MIMIC  program  is  another  example  where 
Raytheon  has  been  involved  in  the  design  and 
development  of  a  design  environment.  As  a 
MIMIC  PHASE  0,  PHASE  I,  and  PHASE  II 
winner,  Raytheon  has  been  involved  in  the 
development  of  an  integrated  design  environment 
which  included  CAD  tools  for  schematic  capture. 


simulation,  physical  layout,  transition  to 
manufacturing.  These  tools  were  transitioned  to 
Cadence  and  Compact  Software  for 
commercialization.  Under  the  MIMIC  funds,  the 
design  and  implementation  of  a  data  base 
environment  to  capture  process  and  test  data  for 
improve  modeling  and  analysis  was  also 
implemented. 


VENDOR  / 
UNIVERSITIES 

DESCRIPTION  OF  WORKING  RELATIONSHIP 

i-Logix,  Inc. 

Developed  algorithms  and  requirements  to  automatically  generate 
behavioral  and  RTL  VHDL  f^m  requirements. 

Mentor 

Developed  requirements  for  Mentor's  probabilistic  fault  grading 
environment  and  Design  Management  System.  Raytheon  has  held  two 
presidential  and  vice-presidential  offices  in  the  International  Mentor 

User's  Group. 

Crosscheck 

First  DoD  contraaor  to  adopt  the  Crosscheck  methodology  and  build 
working  silicon.  Integrated  Crosscheck  tools  with  Mentor  and  Cadence 
tools. 

CAE  Vendor 

Raytheon  is  a  common  beta  test  site  for  several  commercially  available 
CAE  tools,  e.g.  Mentor,  Cadence. 

U.  Cal.  at  Berkeley 

Enhancement  of  Beiiceley's  SPICE  algorithms. 

Compact  Software 

Transitioned  MIMIC  CAD  work  for  commercialization 

Table  3.1-34,  Examples  of  RaytheonIVendorlUniversity  Working 

Relationships 
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The  above  examples  demonstrate  Raytheon 
capabilities  and  understanding  of  the 
requirements  for  system  design  tools,  and  not 
just  point  solutions.  In  addition  to  the  above 
efforts,  Raytheon  has  been  involved  in  the 
development  of  unique  CAD  tools,  such  as 
Express  V-HDL,  with  i-Logix.  Raytheon  co¬ 
developed  this  capability  with  i-Logix  which  was 
commercialized  and  marketed  by  i-Logix.  After 
this  initial  successful  effort,  further  work  was 
done  with  i-Logix  to  allow  for  the  generation  of 
RTL  level  VHDL  which  could  be  synthesized  by 
Synopsys'  Design  Compiler. 

Over  the  years,  Raytheon  has  had  many  working 
relationships  with  vendors  and 


universities.  Table  3.1-34  lists  some  of  these 
relationships.  The  experience  gained  from  these 
relationships  will  help  ensure  successful  working 
relationships  with  RASSP,  and  with  other 
^propriate  government  initiatives. 

Raytheon  is  a  member  of  a  number  of  standards 
organizations  such  as  IEEE,  CFI,  VHDL,  the 
CALS  IWG,  the  PDES  Application  Protocol- 
Electronics  IRB  and  the  IPO/ISO.  In  addition  to 
these  activities,  Raytheon  engineers  have  actively 
participated  in  the  Mentor  User  Group,  and  the 
VHDL  User  Group  and  workshops,  as  well  as 
attending  and  contributing  to  a  number  of 
DARPA  sponsored  workshops. 
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2.2 _ Interoperability  Considerations 

Interoperability  between  current  and  next- 
generation  products  expedites  MODEL  YEAR 
development  programs.  With  this,  upgrades  can 
leverage  a  significant  amount  of  hardware  and 
software  investment  from  previous  versions 
thereby  reducing  development  cost  and  time. 

3.2.1  Hardware  Interoperability 

Electrical  and  mechanical  interface 
interoperability  between  an  existing  and  an 
upgraded  subsystem  provides  a  path  for 
performance  improvement  for  upgrades  that  only 
affect  portions  of  a  signal  processor.  The  ability 
to  upgrade  individual  sections  of  a  signal 
processor  provides  an  environment  suitable  for 
incremental  MODEL  YEAR  improvements. 
Figure  3.2-1  illustrates  a  signal  processor  broken 
into  three  interoperable  sections. 

3.2. H  Current  Approaches  To 
Interoperability 

Currently,  most  application  specific  signal 
rocessors  attain  interoperability  at  the  module 
level  by  making  use  of  standard  system  busses 
and  rack-and-stack  backplanes.  However, 
within  the  signal  processor,  subsections  often 
use  nonstandard  or  custom  interfaces.  The 


digital  signal  processor  interfaces  tightly  to  the 
A/D  front-end  in  order  to  maximize  performance. 
Performance  objectives  are  met  with  this 
approach,  but  subsequent  product  upgrades  are 
usually  forced  to  redesign  the  entire  signal 
processor  because  existing  interfaces  are 
hardwired  and  not  scalable. 

Upgrades  that  effect  the  entire  signal  processor 
are  commonplace  today  because  standard  system 
busses  such  as  VME,  MultiBus  II,  or  even 
FutureBus-i-  do  not  offer  a  high-speed  data 
transfer  network  that  satisfies  the  high-bandwidth 
needs  of  signal  processors.  Initial  RASSP 
processors  will  require  transfer  rates  in  the  range 
of  100  to  500  MegaHertz.  Current  system 
busses  have  too  many  layers  of  protocol  and  too 
much  latency.  As  a  result,  connecting  high¬ 
speed  A/D  and  digital  front-ends  to  standard 
system  busses  for  the  sake  of  attaining 
interoperability  does  not  provide  a  solution.  The 
solution  must  come  from  either  a  to-be- 
determined  standard  for  high-speed  data  transfers 
or  a  configurable,  scalable  interface  that  can 
accommodate  the  requirements  of  next  generation 
upgrades.  Figure  3.2-2  illustrates  the 
undesirable  and  the  preferred  use  of  a  system  bus 
for  interoperability  purposes. 


Figure  3.2-1,  Application  Specific  Signal  Processor  With  Interoperable  Sections 
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Figure  3.2-2,  System  Bus  Use  For  Interoperability 


3.2.1.2  Adopting  A  Standard  For 
High-Speed  Data  Transfers 

An  accepted  industry  standard  for  high-speed 
data  transfers  will  help  to  foster  the  development 
of  interoperable  sections  within  signal 
processors.  This  will  facilitate  independent 
upgrade  of  individual  subsections  thereby 
simplifying  incremental  MODEL  YEAR 
upgrades.  Currently,  no  widely  adopted 


standard  exists  in  this  area.  However,  several  de 
facto  standards  as  well  as  up-and-coming 
interface  products  show  some  promise.  Table 
3.2-3  highlights  some  standards  and  products 
that  may  have  future,  if  not  immediate,  bearing 
on  interoperability. 


Name 

Application 

Area 

Speed 

Approval 

Vendor  Support 

Scalable  Coherent 
Interface  (SCI) 

Very  broad: 
Packet-based  bus 
protocol  operates 
over  unidirectional 
point-to-point  links 

1  GByte/Sec  @  16- 
bits 

1  GBit/Sec  @  bit 
serial 

Won  IEEE 
Standardization 
Approval 
(IEEE  1596-1992) 

Dolphin  SCI 
Technology: 

Chip  samples  by 
Q4’92 

HP-IBM  Standard 
Fiber  Module 

Desktop,  Medical, 
Imaging,  and 
Scientific 
Visualization 

133,  266,  531,  and 
1062  Mbit/Sec 

HP-IBM 

collaboration:  Chip 
samples  by  Q2'92 

MAXBus 

Video 

40MHz 

de  facto 

Datacube,  Inc. 

TABLE  3.2-3,  STANDARDS  AND  PRODUCTS  AFFECTING  INTEROPERABILITY 
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3.2.1.3  Flexible  Interfaces  For 
Interoperability 

In  the  absence  of  widely  adopted  high-speed  data 
transfer  standards,  use  of  configurable  high¬ 
speed  chips  can  provide  sufficient  interface 
flexibility  to  accommodate  adjoining  sections  that 
have  been  upgraded  in  a  MODEL  YEAR 
scenario. 

When  planning  an  upgrade,  the  design  team  must 
consider  interface  problems  resulting  from 
changes  in  frequency,  word  length,  and  duty 
cycle.  In  addition,  any  new  use  of  a  technology 
that  is  not  indigenous  to  the  existing  system 
creates  interface  problems  from  component  level 
on  up.  Table  3.2-4  highlights  typical  interface 


characteristics  thereby  accommodating  new  or 
upgraded  adjoining  subsystems.  This  built-in 
configurability  coupled  with  on-chip  Phase- 
Lock-Loop  (PLL)  circuitry  and  high-speed 
memory  provides  enough  flexibility  to  handle 
changes  in  frequency,  channel  number,  word 
width,  and  duty  cycle.  The  on-chip  PLL  allow  s 
for  interface  clock  ftequency  increases  provided 
that  the  frequency  does  not  exceed  the  limits  of 
the  chip's  implementation  technology.  On-chip 
configuration  registers,  accessible  by  the  IEEE 
1149.1  port,  allow  for  many  arrangements 
between  channels,  word  width  combinations, 
and  duty  cycles  by  controlling  the  organization  of 
the  on-chip  memory.  When  subsystem  upgrades 
necessitate  a  change  in  interface  technology. 


Subsection 

Upgrade 

Interface 

Frequency 

Interface 
Channels  and 
Word  Width 

Sampling  Duty 
Cycle 

Implementation 

Technology 

A/D  converter 

Increases 

Both  Increase 

~ 

GaAs 

High-Speed 

Digital 

Increases 

Both  Increase 

Increases 

CMOS,  ECL  or 
some  combination 

High- 

Performance 

Processor 

Increases 

May  increase  or 
decrease 
depending  on 
architecture 

Variable 

CMOS 

TABLE  3.2-4,  INTERFACE  IMPLICATIONS  FOR  SUBSECTION  UPGRADES 


implications  for  signal  processor  subsection 
upgrades. 

Configurable  high-speed  chips  can  accommodate 
many  of  the  interface  changes  resulting  from 
MODEL  YEAR  upgrades.  The  rightmost 
diagram  of  Figure  3.2-2  illustrates  three 
subsystems  connected  by  configurable  interface 
chips.  These  chips  have  an  IEEE  1149.1  test 
access  port  that  can  be  used  to  change  operational 


designers  can  use  high  level  language  models  to 
synthesize  a  new  implementation  in  the  desired 
technology.  In  the  time  ftame  of  the  first  RASSP 
processor  (1995),  chips  will  have  I/O  cells 
compatible  with  CMOS,  ECL,  and  possibly 
optical  interfaces.  Figure  3.2-5  illustrates  a 
configurable  interface  chip  capable  of 
accommodating  some  of  the  interface  changes 
listed  in  Table  3.2-4. 
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Figure  3.2-5,  Configurable  Interface  Chip 


3.2. 1.4  Interoperability  Trade  Offs 

System  designers  have  much  more  flexibility 
with  a  system  that  exclusively  employs  standard 
interfaces  and  is  functionally  partitioned  at  well 
defined  boundaries.  However,  some  signal 
processors  do  not  lend  themselves  to  such  an 
ideal.  For  example,  high-performance  signal 
processors  usually  require  very  tight  coupling 


between  key  subsystems.  Systems  constrained 
by  very  tight  mechanical  constraints  have  similar 
circumstances.  Often,  this  tight  coupling 
involves  unique  mechanical  and  electrical 
connections  that  are  optimized  for  performance. 
In  many  cases,  technology  translation  may  be 
required  to  maintain  standard  interfaces.  The 
trade-off  is  whether  to  sacrifice  performance  (and 
possibly  increase  life  cycle  costs)  in  order  to 
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maintain  interoperability,  or  to  attain  performance 
at  the  expense  of  interoperability.  It  makes  sense 
to  depart  from  a  strict  policy  of  maintaining 
intrasubsection  interoperability  for  signal 
processors  that  have  very  tight  package 
constraints  or  ultra-high  performance  objectives. 
One  approach  to  managing  this  departure  is  to 
consider  interoperability  in  the  simulation 
domain.  In  this  context,  upgrades  can  be 
functionally  interoperable  at  levels  other  than 
traditional  interfaces.  If  all  else  fails,  a  complete 
redesign  is  always  an  option,  and  perhaps  in 
some  cases,  may  be  the  best  approach  with  these 
circumstances. 

3.2. 1.5  Known  Interoperability 

Problems  And  Considerations 

MODEL  YEAR  upgrades  will  make  use  of  new 
technologies  that  have  voltage  and  packaging 
requirements  that  existing  systems  cannot  meet. 
To  avoid  this  situation,  RASSP  processors  must 
be  designed-for-upgrade.  Packaging,  power 
supplies,  and  distribution  schemes  must  be 
adequate  for  current  and  next  generation 
upgrades.  The  design  team  must  perform  a 
technology  look-ahead  to  ascertain  the  needs  of 
the  next  generation  upgrade.  With  this, 
designers  can  build  enough  provision  into  the 
current  system  to  prepare  for  the  next  generation 
upgrade.  For  example,  a  system  being  built 
today  should  consider  the  requirements  of 
integrating  high-speed  optoelectronic 
components.  The  Optoelectronic  Technology 
Consortium  (OETC)  has  plans  to  develop 
components  capable  of  transmitting  data  at  16- 
Gbits/second.  The  application  area  being 
targeted  is  backplanes,  and  chips  are  due  for 
sampling  in  1995.  Provisions  included  in  an 
existing  system  facilitates  rapid  insertion  of  these 
up-and-coming  devices. 

Maintaining  intrasubsystem  interoperability  by 
strict  use  of  standard  interfaces  has  life  cycle  cost 
and  logistics  implications.  Maintaining  standard 
interfaces  may  require  additional  special  purpose 
components  that  are  difficult  to  procure.  For 
example,  components  may  only  be  available  in 


commercial  or  industrial  grades  thereby  creating  a 
logistical  problem  of  specifying,  inspecting,  and 
procuring  military  versions.  This  will  tend  to 
increase  the  cost  of  development  and  production. 
Ultimately,  the  solution  to  this  problem  rests  with 
a  common  specification  that  is  established  for 
both  military  and  commercial  components.  Only 
then,  will  commercial  components,  which  largely 
adhere  to  industry  standards,  be  completely 
accessible  for  use  in  military  systems.  The 
RASSP  contractors  involved  with 
Implementation  Phase  can  effectively  influence 
working  groups  chartered  with  establishing 
common  specifications,  standards,  and  even 
products. 

3.2.2  Software  Interoperability 

Raytheon  has  developed  and  upgraded  many 
signal  processing  systems  with  embedded  real¬ 
time  software.  Often,  software  interoperability  is 
being  maintained  through  subsystem  upgrades  by 
increasing  the  clock  frequency  while  keeping  the 
same  hardware  architecture.  This  approach 
minimally  effects  the  software  and  results  in 
minimum  risk.  While  this  approach  is 
convenient,  products  do  not  attain  peak 
capabilities  since  new  architectures  offer  paths  to 
higher  levels  of  performance  beyond  what  clock 
frequency  increases  can  provide. 

As  with  hardware,  software  interoperability  is  a 
tradeoff  between  generality  and  performance.  To 
achieve  maximum  performance,  domain  specific 
software  must  exploit  unique  hardware  features 
which,  in  turn,  creates  a  potential  interoperability 
problem  for  the  next  generation  subsystem 
upgrade.  Commercial  DSP  processors  provide  a 
software  compatibility  path  between  product 
generations;  however,  in  order  to  attain  the 
maximum  performance,  engineers  usually  have 
to  modify  software,  particularly  software  written 
in  machine  language. 

Attaining  software  interoperability  between 
successive  upgrades  results  in  reduced 
development  costs,  lower  risk,  and  shorter 
development  time.  Ideally,  software 
interoperability  can  exist  within  upgrades  of 
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domain-specific  embedded  software,  and 
between  upgraded  and  existing  subsystems. 

Ada  compilers  are  available  for  commercial  DSP 
chips.  Ada  has  the  advantage  of  being  the  most 
portable  programming  language  available, 
because  of  the  rigid  vali^tion  procedure  required 
of  vendors.  This  argues  for  the  use  of  Ada  as  the 
standard  language  for  software  interoperability 
among  processors. 

A  gating  factor  to  the  use  of  Ada  in  MODEL 
YEAR  upgrades  is  the  time  delay  for  vendors  to 
produce  validated  Ada  compilers.  In  the 
evolving  Ada  business  model,  compiler  vendors 
are  now  forming  strategic  alliances  with  chip 
vendors,  sharing  technologies,  risk,  and 
royalties.  Such  intimate  knowledge  of  the 
processor  architecture  would  argue  for  a  reduced 
time  to  market.  However,  Raytheon's 
experience  indicates  that  compiler  upgrades  from 
one  chip  type  to  another  (MC68020  to 
MC68030,  for  example)  take  6-9  months,  while 
the  development  of  an  Ada  compiler  for  a 
completely  new  architecture  takes  1  1/2  to  2 
years. 

In  addition  to  compiler  production  delays, 
vendors  use  incremental  releases  each  with 
increasing  optimization  capability.  Initial  releases 
have  relatively  unintelligent  code  generators. 
With  subsequent  releases,  vendors  add  more 
sophisticated  optimization  capabilities  to  the 
compilers.  Raytheon's  experience  is  that  it 
requires  about  3  releases  of  a  compiler  before  it  is 
mature  enough  to  be  used  for  high-speed,  real¬ 
time  applications 

New  concurrent  engineering  approaches  is  one 
possible  solution  for  simultaneously  developing 
new  chip  architectures  and  compilers.  Tools 
enabling  early,  high  level  architecture 
descriptions  coupled  to  compiler  back  ends  offer 
some  hope  of  decreasing  the  lead  time  for 
compiler  availability. 

3.2.2.1  Parallel  Software 

Increasingly,  use  of  parallel  processors  in  signal 
processing  systems  is  becoming  the  norm.  Yet, 


software  poses  a  fundamental  obstacle  to 
exploiting  its  full  potential.  The  following 
paragraphs  list  the  software  problems  associated 
with  this  situation. 

Sequential  software  will  not  run  efficiently  on 
parallel  architectures.  Engineers  must  often 
reprogram  existing  software.  This  includes 
converting  serial  code  to  a  parallel  and/or 
distributed  form  in  order  to  take  advantage  of 
new  machine  architectures.  This  is  labor 
intensive  and  inhibits  reuse  of  source  code.  As  a 
result,  software  productivity  diminishes. 

Programming  parallel  architectures  is  difficult  for 
most  software  engineers.  Designing  and 
programming  for  parallel  architectures  is 
distinctly  different  from  traditional  programming 
for  sequential  machines.  Parallel  programming 
requires  a  different  mind  set.  Training  is 
nontrivial;  it  takes  six  months  or  more  for  a 
programmer  to  become  effective  in  parallel 
programming. 

Current  tools  do  not  work  well  with  parallel 
architectures.  Execution  analyzers,  test  case 
generators  and  other  correemess  checkers  and 
test  aids  generally  do  not  address  the  non 
determinism  introduced  by  interacting  parallel 
processes.  Non  intrusive  test  aids  are  essential 
for  successful  parallel  software  development 
projects. 

Few  software  tools  exist  for  new  parallel 
architectures.  Engineers  have  a  difficult  time 
updating  off-the-shelf  complex  tools.  Similarly, 
tools  for  software  reengineering  have  the  same 
problem. 

A  wide  variety  of  distinctly  different  architectures 
and  machine  languages  exist.  MODEL  YEAR 
upgrades  will  inevitably  result  in  different 
architectures  from  year  to  year.  This  movement 
can  result  in  a  dramatic  change  in  software  tools' 
requirements. 

Despite  parallel  programming  obstacles,  several 
approaches  are  available  to  alleviate  some  of 
these  problems. 

Automatic  translation  tools  can  convert  sequential 
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programs  written  in  high  level  languages  to  a 
parallel  form.  Program  analyzers  can  parse 
sequential  source,  identify  parallelism,  and 
attempt  to  rearrange  or  rewrite  the  program  for  a 
particular  multiprocessor.  Most  of  these 
conversions  require  some  human  intervention  to 
achieve  efficient  execution.  However,  this  is  a 
first  step  in  attaining  interoperability  between 
serial  and  parallel  architectures. 

Nearly  all  developers  of  parallel  machines  offer 
extensive  libraries  of  common  mathematical 
functions  that  execute  efficiently.  Parallel 
machine  assembly  or  high  level  languages  make 
subroutine  calls  to  this  library.  This  is  a  primary 
aid  to  application  programmers.  The  pitfall  here 
is  that  routines  may  contain  bugs,  and  usually  are 
not  validated.  Table  3.2-6  lists  the  characteristics 
of  several  parallel  processor,  vendor  supplied 
libraries. 


Vendor 

Library  Characteristics 

Thinking 

Machines 

Math,  Signal  Proc.  Functions 

Active 

Memory 

Technologies 

Math,  Signal  Proc.  Functions 

WaveTracer 

Math,  Signal  Proc.  Functions 

MassPar 

Math,  Signal  Proc.  Functions 

TABLE  3.2’6,  LIBRARIES  FOR 
PARALLEL  ARCHITECTURES 


Programmers  can  append  special  constructs  to 
standard  languages  that  designate  areas  of  code 
for  conversion  to  parallel  form.  A  compiler  or 
high  level  language  translator  performs  the 
conversion.  The  problem  of  programming  for 
parallel  operations  remains,  but  programmers 
retain  their  basic  programming  skills  by  keeping 
with  a  familiar  language. 

New  Languages  written  expressly  for  parallel 
programming  offer  the  potential  for  efficient 
implementation  and  could  ultimately  produce  a 
standard  language. 


Regardless  of  the  level  of  success  achieved,  none 
of  the  aforementioned  measures  is  satisfactory 
for  embedded  real-time  software  development  for 
MODEL  YEAR  programs.  The  solution  for  the 
embedded  computer  software  community  will  be 
implementation  of  the  MIL-STD-1815  (Ada) 
standard  for  parallel  processing  architectures. 
Ada  is  designed  for  concurrent  execution  of  tasks 
with  process  and  data  synchronizing 
mechanisms.  This  ensures  the  integrity  of 
parallel  operation.  Until  there  are  Ada  compilers 
for  parallel  architectures,  the  embedded  software 
community  will  not  be  able  to  use  parallel 
processing  architectures  effectively.  In  the 
meantime,  embedded  software  developers  who 
need  the  throughput  offered  by  highly  parallel 
computer  architectures  are  gearing  up  to  program 
the  applications  in  assembly  language  using  the 
subroutine  libraries  provided  by  machine 
developers.  Some  software  developers  will 
select  a  parallel  and/or  distributed  architecture  for 
use  in  their  embedded  system.  Then  they  will 
work  with  both  machine  and  Ada  vendors  to 
interface  an  Ada  compiler  and  runtime  system 
with  peculiar  machine  facilities  and  tools.  This 
preserves  their  investment  in  Ada  applications 
source  code  and  avoids  the  Government  Ada 
waiver  process.  In  place  of  industry  standards, 
this  experience  will  provide  an  approach  to 
transporting  Ada  systems  and  applications  to 
future  architectures. 

Government  needs  to  establish  a  parallel 
computer  and  distributed  network  operating 
system  standards.  This  will  facilitate  porting  of 
Ada  compilers,  runtime  environments,  and  tools 
to  various  hardware  architectures.  Existence  of 
standards  in  which  both  machine  developers  and 
Ada  vendors  could  work  towards  would  foster 
interoperability  and  stimulate  the  market  much  in 
the  same  way  that  Unix  (Posix)  and  X-windows 
has  stimulated  the  workstation  market 
3.2.2.2  Real-Time  Software 
Specification 

Real  time  software  specification  strategies 
coupled  with  reusable  software  libraries  can 


55 


UNCLASSIFIED 


facilitate  interoperability  between  MODEL  YEAR 
upgrades.  By  specifying  the  software  at  a 
functional  level,  engineers  can  synthesize  code 
for  any  hardware  platform  provided  that 
compilers  and  libraries  of  reusable  functions 
exist.  The  high  level  specification  provides  a 
global  view  of  the  software  and  allows  engineers 
to  assess  partitioning  and  performance  limits. 
The  synthesis  capability  allows  engineers  to 
choose  hardware  or  software  implementations  for 
functions.  The  reuse  libraries  provide  software 
productivity  improvements  by  containing  a 
majority  of  the  needed  software  functionality. 
Currently,  reuse  makes  up  10-20%  of  software 
builds.  Within  the  next  few  years,  this 
percentage  will  likely  exceed  50%. 


converting  software  from  one  architecture  to 
another.  Raytheon's  experience  has  shown  that 
the  same  algorithm,  coded  identically,  can  have 
up  to  a  lOOx  run  time  difference  when  executed 
on  different  parallel  processors.  Issues  of  data 
partitioning  and  communication  overhead  account 
for  these  differences.  Additionally,  designers 
must  consider  the  entire  signal  processing 
algorithm  flow  when  optimizing  for 
performance.  A  panicular  function,  matrix 
inversion  for  example,  might  be  most  efficient 
within  a  particular  algorithm.  However,  the  next 
algorithm  to  execute  could  find  that  data  in  an 
awkward  configuration.  Therefore,  the  first 
algorithm  runs  efficiently,  but  the  second 
algorithm  runs  inefficiently.  Thus,  locally 


Repository 

Service/Organization 

CAMP  —  Common  Ada  Missile  Packages 

Air  Force 

CARDS  —  Central  Archive  for  Reusable  Defense  Software 

Air  Force 

RAPID  -  Reusable  Ada  Products  for  Information  Systems 
Development 

Army 

ASSET  “  Asset  Source  for  Software  Engineering 
Technology 

DoD 

STARS  "  Software  for  Adaptable,  Reliable  Systems 

DoD 

TABLE  3.2-7,  SOFTWARE  REUSE  REPOSITORIES 


Market  forces  and  the  changing  economy  of 
defense  technology  will  require  contractors  to  bid 
software  programs  with  reuse  being  an  integral 
part  of  the  software  development  plan.  Soon 
enough,  bids  will  not  be  competitive  if  software 
projects  stay  away  from  reuse.  Contractors  will 
have  to  reuse  software  to  be  competitive  in  the 
DoD  arena. 

The  DoD  has  assembled  several  domain-specific 
software  repositories  for  reuse.  Table  3.2-7  lists 
several.  Dial-in  capabilities  are  available  and 
soon  networking  capabilities  will  be  added.  For 
a  fee,  contractors  will  have  access  to  domain- 
specific  libraries. 

A  major  drawback  to  reuse  is  the  difficulty 


optimal  algorithms  may  not  contribute  to  global 
efficiency. 

A  possible  solution  is  to  use  an  optimization 
technique  know  as  "genetic  algorithms."  This 
approach  uses  a  library  of  algorithms  that 
perform  signal  processing  functions.  It  uses  a 
high  level  architectural  model  to  simulate  and 
determine  the  "cost"  of  each  particular  algorithm 
and  resulting  data  partition.  The  genetic 
algorithm  approach  selects  candidates  from  the 
set  of  algorithms  and  potential  data  partitions  by 
using  optimizing  binary  encodings  of  algorithm 
characteristics.  It  manipulates  binary  encodings 
by  evaluating  the  fitness  of  the  algorithms  as 
determined  by  the  simulation  results. 
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2.2 _ Peslqn/Manufagturing-Intgrfflcg 

Considerations 

During  the  RASSP  Study  Phase,  the  team 
investigated  the  critical  elements  of  the  interface 
between  the  RASSP  design  system  and  the 
manufacturing  resource  base  capable  of 
supplying  RASSP  components  and  products.  A 
signal  processor  is  a  complex  electronic  system 
requiring  manufacturing  capability  from 
semiconductor  fabrication  to  multi-module 
assembly.  The  following  attributes  of  the 
design/ rruirurfacturing  interface  were  studied: 

•  The  major  participants  in  the  RASSP 
production  cycle 

•  Design  data  exchanged  with 
manufacturers 

•  Production/process  data  exchange 

•  Standards  modes  of  data  exchange 

•  Developments/progress  required  to 
facilitate  RASSP 

The  industrial  base  for  RASSP  includes  electrical 
component,  Semiconductor.  MultiChip  Module, 
and  Subsystem/  System  assembly  suppliers. 
Electrical  component  suppliers  provide 
commercial  off-the-shelf  products,  such  as 
capacitors  and  resistors,  that  can  be  generally 
purchased  through  catalogs.  Semiconductor 
suppliers  include  both  commercial/standard 
integrated  circuit  devices  and  application  specific 
integrated  circuits  (ASICs).  Multichip  module 
form  the  next  level  of  integration,  consisting  of 
multiple  bare  IC  die  packaged  directly  on  a 
common  substrate.  Substrate  suppliers  include 
silicon  substrates,  low  temperature  cofired 
ceramic  (LTCC),  epoxy  glass,  and  polyimide 
substrate  supplies.  Contract  or  in-house 
assembly  services  complete  the  module  and 
system  assembly. 

Each  of  these  suppliers  must  interact  with  the 
design  agency  and  with  related  suppliers  in  the 
production  ci’  in  to  effectively  produce  a  RASSP 
product.  !  sSSP  users  must  be  capable  of 
entering  the  system  at  multiple  points  of  design 
completion.  The  three  main  entry  points 


emerging  in  electronic  systems  are  at  the 
functional,  the  electrical,  and  the  physical 
description  levels.  At  the  functional  level  the 
design  is  described  through  a  functional 
specification  or  VHDL.  At  the  electrical  level, 
the  design  is  described  through  a  netlist,  a  pans 
list,  and  a  set  of  test  vectors.  At  the  physical 
level,  the  design  is  detailed  including  component 
placement,  routing,  and  documentation. 

In  addition  to  product  design  data,  production 
data  is  exchanged  among  the  suppliers  and  the 
RASSP  user.  Relevant  production  data  includes 
the  following: 

•  Scheduling/Long  Lead  Items/Availability 

•  Cost/Volume/Yield  Models 

•  Process  Capabilities  (including  planned 
product/process  improvements) 

•  (^ality  Information  (Qualification, 
Performance) 

•  Design  Guidelines 

This  data  flows  between  the  RASSP  user  and  the 
supplier  and  among  the  suppliers,  who  must 
coordinate  their  efforts  to  achieve  the  rapid 
turnaround  goals  of  RASSP. 

3.3.1  Production/Procurement 
Services 

To  meet  program  objectives  RASSP  products 
will  rely  heavily  on  ASICs  and  MCMs  to  realize 
the  upgradability  of  the  model  year  approach. 
Design  agencies  will  require  access  to  ASIC  and 
MCM  suppliers  through  a  flexible  manufacturing 
interface.  While  the  ASIC  industry  is  fairly  well 
established,  the  MCM  industry  is  in  its  infancy. 
DARPA  is  seeking  to  establish  a  merchant 
capability  for  Application  Specific  Electronic 
Modules  (ASEMs).  Access  to  ASL.w  foundries 
will  be  facilitated  by  comroor  electronic  data 
exchange  and  an  electroni  ’  okering  system. 
The  structure  of  such  a  b'  .‘^ering  system  is 
depicted  in  Figure  3.3-1.  The  ASEM  brokering 
service  would  provide  a  mechanism  for 
managing  the  acquisition  of  ASEMs  through 
multiple  suppliers.  The  broker  manages  the 
relationships  with  IC  and  MCM  suppliers 
reducing  the  number  of  relationships  to  be 
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managed  by  the  design  organizations.  The 
broker  would  be  responsible  for  qualifying 
suppliers,  understanding  vendor  capabilities  and 
panicular  areas  of  expenise,  and  responding  to 
customer  needs. 

The  ASEM  broker  would  be  responsible  for 
providing  a  network  of  services  including: 

•  Foundry 

•  Die  Supplier 

•  Design  Services 

•  Test 

The  ASEM  customer  can  utilize  the  broker  for  all 
or  some  of  the  brokering  services.  The  customer 
may  want  to  manage  the  design  from  functional 
through  to  physical  layout,  using  the  broker  as  a 
mechanism  to  supply  design  guidelines, 
technology  files  and  libraries.  Alternatively,  the 
customer  may  want  to  provide  just  a  functional 
description  of  the  ASEM,  acquiring  design, 
procurement,  and  test  services. 


The  broker  must  also  work  with  both  die 
suppliers  and  ASEM  foundries  to  establish  and 
maintain  a  viable  network.  The  broker  would 
manage  the  communication  of  data,  capabilities 
and  requirements  among  the  users  and  suppliers. 
The  broker  must  understand  the  capabilities  and 
special  attributes  of  various  suppliers,  and  is 
charged  with  maintaining  information  on  the 
qualification  of  new  and  existing  suppliers. 

3.3.2  Contract  Assembly  Services 

Contract  assembly  services  are  also  available  as 
an  option  for  acquiring  RASSP  product. 
Traditionally,  contract  assemblers  have  been  part 
of  a  network  of  manufacturers  providing  OEMs 
with  assembly  and  test  services.  Contract 
assemblers  are  now  moving  towards  more  full 
service  capacity  including  complete  responsibility 
for  the  manufactured  product.  Full  service 
includes  acquisition  and  management  of  all  the 
component  parts  of  the  assembly.  Essentially, 


Tostsd  OI« 


Figure  3.3-1,  ASEM  Broker 
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the  user  works  directly  with  the  contractor  who 
manages  the  entire  manufacturing  function.  The 
contractor  takes  responsibility  for  the  quality  and 
delivery  of  the  components  and  subsystems. 
They  also  provide  users  with  design  guidelines 
and  work  jointly  on  new  process  development. 

3.3.3  A  PWB  Design/Manufacturing 
Interface  Example 

Raytheon  has  implemented  a  system  that  links 
commercial  PWB  design  systems  to 
manufacturing  through  a  common  database 
structure,  standard  interfaces,  and  a  set  of 
application  programs.  This  system  has  reduced 
the  number  of  point  to  point  translators  required 
between  systems  and  led  to  a  reduction  in  non¬ 
recurring  engineering  effort  for  production  start¬ 
up.  See  Figure  3.3-2  The  system  supports 
Plated  Through  Hole,  Surface  Mount,  Blind 
Pin/Buried  Via,  and  Hybrid  technologies.  Since 
Raytheon  has  multiple  design  and  manufacturing 
sites  that  employ  different  CAD  tools,  one  of  the 
goals  of  the  system  was  to  implement  an 
architecture  that  would  enable  a  design  to  be 


transitioned  into  any  one  of  the  manufacturing 
facilities  with  the  required  capabilities. 

The  design/manufacturing  interface  is  based  on  a 
vendor  independent  neutral  file.  The  neutral  file 
is  generated,  through  translators,  from  Racal 
Redac's  Visula,  Harris'  SCICARDS,  and 
RAPIDS  (an  in-house  tool).  By  employing  a 
neutral  file,  dependence  on  a  single  vendor,  and 
the  number  of  translators,  are  minimized.  A 
Computervision  CADDS4X  database  is 
constructed  from  a  translation  of  the  neutral  file 
for  use  in  manufacturing. 

At  manufacturing,  non-recurring  engineering 
effort  has  been  reduced  through  a  set  of 
application  tools  that  prepare  the  manufacturing 
technical  data  package.  TTiis  includes  preparation 
of  Numerical  Control  tapes  that  drive  the 
fabrication  and  assembly  equipment,  outputs  for 
bare  board  and  in-circuit  test,  and  computer  aided 
process  planning.  The  NC  tapes  are  produced 
from  the  output  of  a  program  that  plans,  through 
simulation,  the  optimal  insertion  sequence  based 


Figure  3.3-2,  PWB  Transition  Database 
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Application  Highlights 

Product  Data 

PWB  Drill/Routing 

Oeates  NC  programs  that  drive 
drillAxjut  equipment 

XY  Locations,  PWB  outline. 
Coupons 

PWB  Panelizadon 

Oeates  multi-image  panelized 
artwork 

Artwork,  coupons 

Bare  Board  Test  Prep 

Qeates  bare  board  test  program 

Netlist 

In-C}ircuit  Test 

(Creates  In-Circuit  test  program 

Netlist,  Parts  list.  Comp, 
values 

EullSSiSSSHBBi 

Creates  component  sequence  list 
and  location  file  post  processed 
for  insertion  equipment 

Component  dimensions,  types, 
board  layout 

Process  Planning 

Creates  operation  sequence, 
operator  instructions,  labor 
standards,  manufacturing  BOM 

CAD  database  (netlist,  parts  list, 
board  layout,  geometry,  part 
properties  etc.) 

Visual  Aid  Generation 

Automatically  creates  visual  aid 
pages  for  display  on  shop  floor 
teiminals 

CAD  Database 

TABLE  3.3-3  NRE  APPLICATIONS  FROM  INTERFACE 


on  component  types,  placement  location,  and 
insertion  equipment  tooling  clearance 
requirements.  The  CAPP  program  plans  the 


Equipment  Type 

Vendor/Model 

PWB  Drill/Rout 

Excellon,  Tru-Drill 

Bare  Board  Test 

DITMCO,  Integri-Test 

In-Circuit  Test 

HP  3065,  Genrad 

Axial  Component 
Inserter 

Universal  SSVCD 

Dynapert 

Radial  Component 
Inserter 

Universal 

DIP  Component 
Inserter 

Universal  MultiMode 

SMT  Device  Pick  & 
Place 

Quad  Systems,  EPE 

TABLE  3.3-4  PRODUCTION 
EQUIPMENT 


sequence  of  factory  operations  required  for 
fabrication  and  assembly,  and  provides  interfaces 
to  a  paperless  operator  display  system  and 
factory  Manufacturing  Resource  Planning 
(MRP).  A  summary  of  the  application  programs 
and  the  production  equipment  that  are 
programmed  from  the  database  is  provided  in 
Tables  3.3-3  and  3.3-4. 

3.3.4  On-Line  Process  and  Cost 
Feedback 

To  ensure  the  "first  pass  success"  designs,  the 
manufacturing  characteristics  of  RASSP 
components  must  be  an  integral  part  of  early 
assessment/analysis  tools.  RASSP  products  will 
consist  of  advanced  electronic  components, 
modules,  and  assemblies;  Each  of  these  must  be 
part  of  an  early  manufacturability  assessment. 
The  following  sections  describe  two  efforts, 
DKTE  Manufacturing  Optimization  (MO)  and  the 
Monolithic  Microwave  Integrated  Circuit 
(MMIC),  that  characterize  manufacturing  data  for 
design  trade-offs.  Both  programs  have  been 
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development  ideas. 

The  MO  system  is  a  conceptual  refinement  to  the 
DICE  virtual  tiger  team  concept.  In  the  present 
DICE  virtual  tiger  team  model,  all  functions  are 
represented  and  linked  concurrently  to  the 
product  design  at  a  single  tier.  MO  proposes  a 
two  tier  approach  with  a  virtual  product  team 
having  a  global  view  supported  by  information 
supplied  by  the  virtual  process  teams(  See  Figure 
3.3-5).  The  rationale  for  this  refinement  is  based 
on  the  growing  complexity  of  both  the  products 
and  supporting  development  processes.  It  is 
increasingly  difficult  to  have  one  representative 
adequately  support  a  manufacturing  (or  logistics) 
position  that  involves  numerous  specialized 
process  areas.  In  practice,  the  assigned 
representative  is  usually  a  specialist  in  one  of  the 
process  areas  and  has  only  generalized 
knowledge  about  the  other  processes.  The 
“virtual  process  team”  would  enable 


Printed  Wiring  Board  Circuit  Card 
Fabrication  Assembly 


funded  by  DARPA. 

3.3.5  DICE  Manufacturing 
Optimization 

The  DARPA  Initiative  in  Concurrent  Engineering 
(DICE)  program  has  been  chartered  with 
developing  technology  that  enables  concurrent 
engineering.  Part  of  the  DICE  concurrent 
engineering  model  is  a  replication  of  the  human 
tiger  team  concept  that  has  been  successfully 
used  on  small  scale  projects  to  bring  high  quality 
products  to  market  quickly.  The  basic  tenet  of 
the  human  tiger  team  is  to  have  the  various 
specialists  contributing  to  the  project  co-located. 
In  today’s  environment  of  complex  product 
designs  and  geographically  dispersed  specialists, 
DICE  envisioned  a  “virtual  tiger  team”  working 
on  a  “unified  product  model”  accessible  by 
computer  networks.  Such  an  environment  must 
enable  specialists  from  each  functional  area  to 
work  on  the  design  concurrently  and  share 


Figure  3.3-5,  Two  Tiered  Team  Concept 


I 

I 


61 


UNCLASSIFIED 


representation  from  all  the  process  areas.  The 
product  team  would  concentrate  on  using  the 
analyses  supplied  by  the  process  teams,  and 
determine  the  best  plan  by  taking  into  account  the 
existence  or  implementation  of  manufacturing, 
logistics,  or  test  plans.  The  product  team  would 
be  responsible  for  decisions  that  span  cross¬ 
functional  expertise. 

The  virtual  process  team  is  an  extension  of  the 
product  team.  It  will  consist  of  specialists 
representing  all  the  various  processes.  For 
instance,  a  process  team  for  a  complex  electro¬ 
mechanical  assembly  might  consist  of  a  Printed 
Wiring  Board  Fabrication,  Circuit  Card 
Assembly,  Cable/Wire  Harness,  and  Sheet  Metal 
representatives.  They  will  have  access  to  the 
unified  product  database  and  will  be  responsible 
for  the  manufacturing  inputs  to  the  product  team. 
Each  member  of  the  process  team  will  review  the 
design,  perform  a  manufacturability  analysis,  and 
make  design  or  process  change 
recommendations.  The  product  team  will  then 
negotiate  with  the  process  team  to  arrive  at  a 
position  (and  perhaps  alternatives)  consistent 
with  the  manufacturing  plan. 

The  virtual  process  team  will  be  supported  by  a 
set  of  tools  that  implements  a  concurrent  Design 
For  Manufacturing/Assembly  (DFMA)  system. 
These  tools  will  enable  the  manufacturing 
process  team  to  perform  individual  DFMA 
analyses,  merge  and  review  these  analyses,  and 
negotiate  trade-offs  among  the  processes.  A 
consolidated  report  and  recommendations  is 
passed  back  to  the  product  team. 

The  MO  system  consists  of  five  major  functions: 
a  process  analyzer,  a  guidelines  analyzer,  a  yield 
&  rework  analyzer,  a  cost  estimator,  and  a 
manufacturing  advisor.  The  process  analyzer 
performs  the  initial  analysis  on  the  design  to 
determine  the  manufacturing  process  (a  set  of 
operations)  required  to  produce  the  part.  The 
guidelines  analyzer  captures  design  for 
manufacturing  and  assembly  guidelines  and 
associated  recommendations.  When  guidelines 
are  violated,  the  violation  and  the  associated 


recommendation  are  recorded.  The  yield  & 
rework  analyzer  calculates  yield  and  rework 
values  by  performing  a  look  up  of  design 
features  versus  an  operation.  The  cost  estimator 
calculates  cost  for  each  operation  used  to  produce 
the  pan.  The  manufacturing  advisor  analyzes  the 
data  generated  by  the  individual  analyses  and 
guides  the  negotiation/trade-off  process  by 
identifying  major  cost  drivers  and  guideline 
violations.  It  recommends  design  alternatives 
based  on  the  influence  of  the  design  parameters 
on  the  cost  analysis  and  produces  the  output  of 
the  process  team  that  gets  passed  to  the  top  tier 
product  team. 

The  MO  system  incorporates  technology 
developed  under  the  early  phases  of  the  DICE 
program.  This  technology  includes  the  STEP 
Tool  Kit,  the  Project  Coordination  Board,  the 
Communications  Manager,  and  Product  Track. 

The  STEP  Tool  Kit,  from  STEP  TOOLS  Inc.,  is 
an  object-oriented  information  management 
system  that  supports  the  product  exchange 
standards  emerging  for  the  PDES/STEP 
standards  activity.  The  tool  kit  includes  an 
EXPRESS  compiler  and  a  set  of  utilities  for 
managing  databases.  The  tool  kit  employs  a  data 
model  that  allows  the  differences  between  two 
design  versions  to  be  computed  as  a  delta  file. 
Using  this  mechanism,  design  alternatives  can  be 
explOTed  by  multiple  team  members  concurrently 
and  the  final  solutions  merged. 

The  Project  Coordination  Board  (PCB)  is  a 
system  being  developed  to  provide  support  for 
the  coordination  of  the  product  development 
activities  in  a  cooperative  environment.  The  PCB 
provides  common  visibility  and  change 
notification  through  the  common  workspace 
(CW),  planning  and  scheduling  of  activities 
through  the  task  structure,  monitoring  progress 
of  product  development  through  the  product 
structure  (i.e.  constraints),  and  computer 
support  for  team  structure  through  messages. 
The  Communications  Manager  (CM)  is  a 
collection  of  modules  that  facilitates  distributed 
computing  in  a  heterogeneous  network.  It 
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promotes  the  notion  of  a  virtual  network  of 
resources  which  the  project  team  members  can 
exploit  without  any  prior  knowledge  of  the 
underlying  physical  network.  Both  the  PCB  and 
the  CM  were  developed  at  the  Concurrent 
Engineering  Research  Center  (CERC)  of  West 
Virginia  University. 

Product  Track,  From  CIMFLEX  Teknowledge, 
is  a  system  designed  to  manage  product 
requirements,  specifications  and  corporate 
policies  to  support  concurrent  engineering.  The 
system  allows  the  users  to  define  requirements 
for  a  project  or  incorporate  standard  requirements 
through  pointers  (file  name).  The  system  also 
tracks  parties  interested  in  specific  requirements 
and  provides  notification  capabilities  upon 
modification  to  that  requirement.  Status  updates 
could  include  modifications  of  a  requirement, 
product  design  driven  violations  of  a 
requirement,  or  satisfaction  of  a  requirement. 

3.3.6  MMIC  Process/Cost  Database 

The  successful  design  and  manufacture  of  MMIC 
components  and  modules  is  dependent  on  an 
integrated  system  that  enables  the  chip  or  module 
developer  to  design  and  analyze  an  IC  based  on 
electrical,  material,  and  process  characteristics. 

While  typical  chip  design  requires  contemplation 
of  these  characteristics,  in  MMIC  design,  the 
ability  to  utilize  process  characteristics  to 
influence  design  trade-offs  is  accentuated  by  the 
criticality  of  process  on  the  resulting  performance 
characteristics  of  the  chip. 

One  thrust  of  the  MIMIC  Program  was  to 
identify  those  process  characteristics  that 
influenced  design  manufacturability.  Early  on,  it 
was  determined  that  the  best  approach  to  this 
problem  was  to  define  and  implement  a  database 
system  to  provide  a  data  repository  for  process 
performance.  This  database,  insened  into  the 
Raytheon  foundry  in  Q1  1991  has  resulted  in  real 
time  data  usage  and  an  in-depth  understanding 
that  has  already  increased  manufacturing 
efficiency  and  improved  product  cost  and  yield. 

In  order  to  satisfy  the  requirements  of  successful 


design  and  manufacture  of  state  of  the  art 
MMICs,  actual  production  process  parameters 
are  collected  in  the  database  at  key  checkpoints 
throughout  the  manufacturing  process. 

The  database  functionality  enables  the  collected 
data  to  be  aggressively  and  creatively  analyzed. 
For  example,  statistical  analysis  of  RF 
performance  data  has  been  difficult  in  the  past 
due  to  the  need  to  simultaneously  understand  the 
fi?equency  variation  of  the  device  which  is  design 
dependent  and  the  manufacturing  variations 
which  are  a  combinations  of  random  and 
systematic  factors.  Efforts  such  as  plotting  all  of 
the  individual  responses  on  the  same  graph 
obscure  the  comparison  with  too  much  detail. 
The  introduction  and  use  of  advanced  data 
organization  and  analysis  tools  has  enabled 
innovation  in  displaying  and  evaluating  RF 
performance  data  which  has  been  useful  in 
determining  appropriate  production  specifications 
for  new  designs. 

In  order  to  define  the  process  variables  that  effect 
the  manufacturability  of  a  design,  causal 
relationships  must  be  determined.  The  database 
has  been  fundamental  to  the  examination  of 
multi-discipline  data.  For  example,  analysis  of 
materials,  dc  and  RF  performance  done  at 
Raytheon  suggests  that  the  processing  history 
has  a  much  stronger  effect  on  the  resulting  output 
power  than  the  starting  material  has  and  any 
effect  of  the  starting  material  on  average  RF 
performance  is  perhaps  swamped  by  the 
processing.  As  a  result,  material  characteristics 
have  not  been  considered  in  the 
design/manufacturability  trade-off.  Rather, 
concentrating  on  process  data,  actual  s-parameter 
data  has  been  incorporated  into  the  design  library 
models,  thereby  providing  accurate  models  of 
circuit  behavior  to  be  used  in  subsequent  design 
iterations. 

Additionally,  the  database  captures  cost/yield 
information  that  can  be  used  with  other 
production  data  to  analyze  capacity  and 
scheduling  requirements  and  influence  business 
plans. 
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3.4  Manufacturing  Considerations 

The  need  for  small  size  and  weight  is  essential 
for  a  broad  range  of  military  applications. 
Military  electronic  trends  have  shown  a  decrease 
in  feature  size  at.''  an  increase  in  packaged 
functionality  over  time.  In  the  past,  integration 
has  taken  place  at  the  silicon  level,  but  as  IC 
devices  push  increasing  lead  counts,  packaging 
technology  has  become  the  limiting  factor. 
Packaging  technology  selection  is  a  trade-off 
among  the  requirements  for  speed,  density, 
testability,  and  cost. 

Conventional  packages  such  as  Quad  Flat  Packs 
(QFPs),  Pin  Grid  Arrays  (PGAs),  and  Tape 
Automated  Bonding  (TAB)  can  get  too  large  and 
require  lead  pitches  so  fine  that  they  get  hard  to 
work  with.  Additionally,  QFPs  are  difficult  to 
test  because  probes  that  touch  the  leads  affect 
copanarity. 

At  high  lead  counts,  PGAs  and  Flip  Chip  are  two 
main  options,  but  are  relatively  expensive.  These 
are  typically  used  to  package  expensive  die.  For 


mass  produced  ICs,  the  packaging  cost  would 
remain  relatively  high  while  the  die  costs  would 
drop. 

Soldering  and  rework  become  major  issues  as 
lead  pitch  shrinks.  Defect  rates  and  cost  increase 
sharply  as  lead  pitch  drops  below  25  mils. 

Multichip  modules  (MCMs)  are  emerging  as  an 
answer  to  the  packaging  problems  stated  above. 
A  number  of  technologies  are  available  for 
MCMs  including: 

MCM-L:  Laminate  -  High  density  laminated 
PWBs. 

MCM-C:  Ceramic  -  Multilayer  ceramic 
substrates.  Usually  co-fired. 

MCM-D:  Deposited  -  High  density  thin  film 
dielectric  and  interconnect  metal  on  a 
supporting  substrate. 

Availability  of  known  good  die  and  multiple 
sources  are  impeding  the  wide  spread  use  of 
MCMs.  The  ASEM  program  seeks  to  build  an 
infrastructure  to  support  a  merchant  capability  for 
MCMs. 
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3.5  Testing  Procedures 

The  RASSP  model  year  concept  requires  that  test 
procedures  become  more  Adaptable  and  cost 
effective  at  all  levels  of  an  electronic  system's 
design.  Standardized  approaches  to  testing  must 
be  jointly  developed  by  both  the  military  and  the 
commercial  industry  to  ensure  that  testing 
procedures  become  more  flexible.  It  is  critical  to 
design  test  capabilities  into  a  system,  allowing 
rapid  insertion  of  cost  effective  hardware  and 
software  upgrades. 

3.5.1  Major  issues 

Historically,  test  has  accounted  for  40-50%  of 
electronic  system  development  costs.  The 
changing  military  environment  is  focused  on 
continued  budget  cuts,  and  increased  weapon 
system  mobility.  Programs  such  as  the  US  Air 
Force  F-22  Advanced  Tactical  Fighter  (ATF), 
and  the  US  Army  RAH-66  Light  Helicopter  (LH) 
have  emphasized  the  need  for  common  test 
programs  for  manufacturing,  depot,  and  field 
support  to  reduce  life  cycle  testing  costs,  and  to 
increase  weapon  system  mobility. 

The  RASSP  concept  requires  that  hardware  and 
software  upgrades  to  signal  processors  be 
designed,  manufactured,  tested,  fielded  and 
maintained  in  a  timely  manner.  In  order  to 
achieve  this,  two  fundamental  objectives  must  be 
met;  1)  reduce  the  cost  and  time  of  test  program 
development  and  transportability;  and  (2) 
improve  the  degree  of  diagnostics  in  both  the 
factory  and  the  field. 

Because  of  the  life  cycle  time  over  which  a 
weapon  system  must  be  maintained,  a  depot 
tester  may  become  obsolete,  and  need  to  be 
replaced  when  technology  upgrades  to  a  weapon 
system  are  made.  A  major  issue  with  replacing 
testers  is  that  test  program  sets  (TPS)  must  be 
transported  from  the  installed  tester  to  the 
replacement  tester.  A  test  program  set  includes 
both  test  programs  and  test  fixtures.  The  time 
and  cost  of  transporting  a  TPS  manually  make  an 
automated  TPS  transporting  system  necessary. 
Portions  of  existing  test  programs  must  be  re¬ 


used  through  a  system  that  supports  a  re-usable 
library.  The  use  of  industry  standards  for 
describing  product  data,  test  strategy  data,  and 
test  procedure  data  is  a  necessaiy  part  of  this  TPS 
transporting  system. 

To  expedite  the  testing  process  for  first  article 
product,  it  is  necessary  to  provide  a  test  system 
and  methodology  that  suppons  the  automatic 
comparison  of  test  equipment  measurements  to 
simulation  results.  Test  systems  today  are 
disjoint  from  the  design  tool's  environment.  The 
process  verifying  first  article  product  is  batch 
oriented.  Typically,  many  iterations  are 
necessary  in  transferring  test  data  to  the  test 
station  from  the  design  tools  to  diagnose  failures. 
A  tight  link  between  the  CAE  design  verification 
environment,  and  the  physical  test  station  should 
be  developed.  This  new  environment  would 
allow  the  design  engineers  to  exhaust  what-if 
scenarios  during  initial  prototype  debug  more 
effectively. 

Integrated  Diagnostics  (ID)  provides  a  structured 
process  that  maximizes  the  effectiveness  of 
diagnostics  by  coordinating  diagnostic  and 
testability  requirements  from  the  factory  to  the 
field.  This  process  provides  a  cost  effective 
capability  to  detect  and  isolate  all  faults  known  or 
expected  to  occur  in  a  weapon  system. 
Testability  analysis  is  the  process  of  assessing 
the  inherent  ability  to  test  the  design  using  the 
prescribed  test  equipment  and  procedures.  This 
has  traditionally  been  an  ad-hoc  manual  effort  in 
which  engineers  analyze  how  the  design  will  be 
tested  later  in  the  weapon  system  life  cycle  based 
on  the  target  test  equipment  and  procedures. 
Some  testability  tools  are  available  today, 
however  the  present  tools  have  drawbacks  that 
limit  their  usefulness.  For  example,  many  tools 
require  a  tedious  detailed  level  of  modeling  that 
do  not  allow  for  global  test  strategy  analyses. 
The  RASSP  process  requires  tools  that  can 
effectively  provide  and  support  the  automation  of 
Integrated  Diagnostics.  Specifically,  tools  that 
provide  analysis  during  preliminary  design  based 
on  functional  models  of  the  s>  stem. 


67 


UNCLASSIFIED 


To  satisfy  the  objective  of  providing  increased 
weapon  system  mobility,  and  better  suppon  for 
maintenance  and  diagnostics  in  the  field,  built  in 
test  (BIT)  must  be  utilized.  The  transfer  of  test 
equipment  specific  testing  to  BIT  increases  the 
system's  availability,  and  avoids  the  cost, 
logistical  suppon  and  training  required  by  unique 
test  equipment.  This  kind  of  BIT  can  be  utilized 
in  real  time  scenarios.  It  can  advise  the  crew 
when  failures  occur  in  the  field  during  mission 
operation.  The  RASSP  model  year  requires  a 
BIT  approach  to  satisfy  rapid  field  deployment 
and  maintenance  requirements.  BIT  also  aids  in 
supplementing  test  equipment  limitations  when  at 
speed  performance  testing  is  necessary. 

ATE  vendors  specify  the  performance  of  their 
test  equipment  based  on  best  case  conditions. 
For  example,  state-of-the-an  test  equipment 
today  is  specified  to  provide  clock  rates  of  80 
MHz,  and  data  rates  of  50  MHz.  These  are 
impressive  numbers,  however  if  at  speed 
dynamic  testing  must  be  performed,  the  numbers 
become  less  impressive.  When  parameters  such 
as  slew  rate,  maximum  skew,  resolution,  and 
burst  length  are  considered,  a  50  MHz  ATE  can 
turn  into  a  20  MHz  ATE.  It  is  up  to  the  system 
house  to  calibrate  TPS's  at  worst  case.  Other 
factors  that  degrade  ATE  performance  include 
insufficient  number  of  timing  generators  and 
timing  sets.  Timing  generators  and  timing  sets 
are  ATE  terms  that  allow  timing  to  be  mapped  to 
the  unit  under  test  (UUT)  pins.  Today,  this 
capability  is  limited.  A  dynamic  test  program 
must  have  flexibility  to  map  timing  that  was 
applied  within  a  simulation  environment  to  the 
test  environment. 

RASSP  will  be  taking  advantage  of  the  increased 
speed  and  density  associated  with  state-of-the-art 
integrated  circuits  in  conjunction  with 
miniaturized  substrates  on  which  they  are 
assembled.  This  state-of-the-art  technology 
poses  new  challenges  in  the  area  of  at-speed 
testing.  New  structural  design  techniques  such 
as  the  1149.1  test  bus  standard  are  useful  in 
testing  the  structural  integrity  of  interconnects 


between  devices  on  a  module,  but  cannot  be  used 
effectively  for  at-speed  testing.  Test  instruments 
such  as  logic  analyzers  and  guided  probe  will  no 
longer  have  the  physical  access  needed  to 
monitor  nodal  states  for  at  speed  testing. 
Therefore,  new  approaches  are  needed  to 
overcome  the  inability  for  test  instruments  to  gain 
access  to  nodal  states  in  order  to  perform  at- 
speed  functional  testing.  High  speed  signal 
processors  will  require  embedded  test 
techniques.  The  RASSP  model  should  include 
the  top  down  design  of  embedded  test  controller 
chips  that  can  act  as  monitors  of  critical  bus 
signals  within  the  unit  under  test  (UUT).  The 
test  equipment  would  interface  with  the  test 
controller  chips  in  a  mode  that  initiates  the 
embedded  test  programs,  and  then  the  test 
equipment  would  detach  itself  from  the  test 
operation  until  the  embedded  test  program 
completes.  At  that  point,  a  result  in  the  form  of  a 
signature  could  be  read  out  via  the  test 
equipment. 

3.5.2  Possible  Solutions 

As  the  model  year  provides  for  multiple 
technology  upgrades  of  a  weapon  system,  it  is 
necessary  to  provide  a  test  system  that  is  part  of 
the  RASSP  design  environment  which  has  the 
objective  of  supporting  a  coordinated  refinement 
of  design  and  test  requirements.  As  the  design 
process  transitions  from  system  design 
requirements  to  top-level  design  to  detailed 
design,  so  too  should  the  test  procedures.  High 
level  test  requirements  should  be  captured  in 
standards  such  as  the  test  requirements 
specification  language  (TRSL),  and  checked 
against  high  level  design  requirements 
represented  in  VHDL.  Test  program  data 
represented  in  WAVES,  Ada,  and/or  ATLAS 
should  be  checked  against  the  top  level  design 
data  represented  in  VHDL.  A  tool  set  should  be 
developed  that  supports  this  concept  of 
coordinated  refinement.  Test  must  be  part  of  the 
design  process. 
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3.5.2.1  Translation  System  For  TPS 
Development 

To  reduce  the  time  and  cost  of  transporting  test 
programs  to  multiple  test  environments,  a 
translation  system  should  be  developed  that 
provides  automated  generation  and  maintenance 
of  electrical  test  specifications  and  test  programs. 
The  system  would  provide  the  capability  to 
develop  test  program  sets  and  test  specifications 
based  on  standard  data  formats.  The  translation 
system  would  manage  the  product  and  test  data 


(TRS)  would  be  in  an  industry  standard  form 
such  as  TRSL.  The  test  requirements  definition 
process  would  consist  of  a  tool  that  would  guide 
the  design  and/or  test  engineer  through  the 
generation  of  the  TRS.  The  test  specification 
would  then  be  captured  in  a  database  for  life 
cycle  support.  This  database  representing  high 
level  test  requirements  would  then  be  used  to 
generate  target  test  programs  in  industry  standard 
formats  such  as  Ada,  ATLAS  and  WAVES. 

The  TPS  post  processor  step  allows  for  the 


Figure  3.5-1,  TPS  Data  Flow 


over  the  life  cycle  of  the  weapon  system.  Figure 
3.5-1  represents  a  functional  flow  of  such  a 
translation  system. 

Product  design  data  in  the  form  of  VHDL, 
WAVES,  ED  IF  etc.  would  drive  the  process  of 
generating  a  test  requirements  specification 
(TRS).  The  test  requirements  specification 


generation  of  TPS's  independent  of  the  target 
test  equipment  being  used.  This  process  would 
incorporate  the  concept  of  a  knowledge  based  re¬ 
usable  library.  The  TPS  post  processor  "IN¬ 
STEP"  developed  by  Harris  under  contract  via 
the  Tester  Independent  Support  Software 
System  (TISSS)  program  should  be  evaluated  for 
applicability  to  RASSP.  IN-STEP  successfully 
demonstrated  TPS  re-targeting  for  an  advanced 
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tactical  fighter  (ATF)  line  replaceable  module 
(LRM). 

This  approach  to  test  program  development 
would  support  the  RASSP  model  year  concept 
by  reducing  the  time  and  cost  associated  with 
developing  initial  test  programs,  and  the  time  to 
transpon  the  test  programs  for  testers  in  the  field. 
On-going  DoD  initiatives  in  TISSS,  Ada  Based 
Environment  For  Test  (ABET),  Modular 
Automated  Test  Equipment  (MATE), 
Consolidated  Automated  Support  System 
(CASS)  should  all  be  evaluated,  and  applicable 
technology  utilized  in  the  RASSP  concept. 

3.5. 2.2  Design/Test  Interactive  Link 

Another  aspect  that  would  decrease  the  test 
development  time  would  be  a  simulation  system 
that  in  an  on-line  fashion  communicates  with  the 
unit  under  test  (UUT).  As  Figure  3.5-1 
illustrates,  this  simulation  system  would  actually 
communicate  with  the  test  equipment  via  a 
telecommunications  link.  The  simulation 
platform  would  emulate  the  specific  test 
equipment  behavior  up  front  to  ensure  that  test 
patterns  are  compatible  with  the  target  test 
equipment.  The  specifics  of  the  test  equipment 
resources  would  be  represented  in  an  industry 
standard  format  such  as  the  Test  Equipment 
Description  Language  (TEDL)  or  the  Resource 
Description  Language  (RDL).  The  test  program 
to  be  simulated  would  be  represented  in  either 
Ada,  WAVES,  ATLAS,  or  a  combination  of  the 
formats.  This  same  test  program  format  would 
be  used  to  drive  the  test  equipment.  In  addition, 
expected  responses  can  be  compared  against  test 
equipment  measurements  automatically.  Any 
discrepancies  would  be  flagged  on  the  simulation 
workstation  in  the  form  of  graphical  wave  forms. 
The  design  and/or  test  engineer  can  then  rapidly 
debug  the  first-article-product  by  exercising 
what-if  scenarios  quickly.  First-article  product 
problems  such  as  design  errors,  vector  errors,  or 
manufacturing  defects  can  be  isolated  more 
quickly. 

3.5.2.3  BIT/BITE  Insertion 

The  RASSP  model  year  concept  must  support  the 


need  for  increased  diagnostics  with  less 
dependence  on  supporting  test  equipment.  This 
can  be  achieved  through  the  use  of  increased 
BIT/BITE  insertion.  The  BIT/BITE  insertion 
must  be  part  of  the  RASSP  design  process.  A 
testability  advisor  tool  that  works  at  the  high  level 
should  be  used  to  advise  on  a  BIT  architecture 
for  a  system. 

As  Figure  3.5-2  illustrates,  the  design  for  test 
(DFT)  tool  would  be  used  early  in  the  product 
life  cycle  when  hardware/software  partitioning 
decisions  are  made.  The  tool  would  take  as  input 
a  VHDL  behavioral  representation  of  the  system. 
This  VHDL  description  describes  the  architecture 
of  the  system  by  specifying  functional  blocks  and 
their  dependencies  on  each  other.  Another  input 
to  the  tool  is  the  testability  and  diagnostic 
requirements.  Issues  such  as  degree  of  fault 
isolation,  level  of  fault  coverage,  and  test  time 
constraints  are  examples  of  test  requirements. 
The  test  requirements  would  be  in  the  format  of 
the  proposed  IEEE  Test  Requirements 
Specification  Language  standard  (TRSL).  A 
third  input  to  the  advisor  tool  is  data  that 
describes  technology  specific  information  such  as 
reliability  data  and  yield  parameters. 

The  tool  would  work  off  of  a  knowledge  base 
that  contains  global  test  strategies.  Examples  of 
the  global  test  strategies  that  are  included  in  the 
knowledge  base  are:  Built-In  Self  Test  (BIST) 
descriptions  of  sub-functions,  test  controller 
chip  architectures,  types  of  scan  path 
implementations,  types  of  BIT  associated  with 
COTS  (commercid  off  the  shelf)  and  SEM-E 
modules.  The  advisor  would  then  identify  where 
testability  is  lacking  and  recommend  where  BIT 
should  be  incorporated.  The  key  objective  is  to 
identify  diagnostic  requirements  early  so  that  they 
can  influence  the  overall  design  architecture  of  a 
system. 
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3.5.2.4  Integrated  Diagnostics 
Design  Tools 

In  order  to  reduce  the  time  and  cost  of 
implementing  Integrated  Diagnostics,  the  RASSP 
model  year  concept  must  include  a  set  of  tools 
that  help  automate  the  process.  These  tools  must 
meet  certain  requirements.  First,  the  tools  must 
be  simple  and  easy  to  use.  This  is  very 
important  for  those  tasks  that  must  be  performed 
early  in  the  design  cycle  due  to  tight  schedules. 
Second,  the  tools  must  be  able  to  support  all 


allocated  more  efficiently. 

Figure  3.5-2  illustrates  an  environment  that 
stresses  that  test  activities  must  be  part  of  the 
entire  product  life  cycle.  More  specifically,  the 
automation  of  test  activities  must  be  part  of  the 
concurrent  engineering  design  system.  Figure 
3.5-2  also  emphasizes  that  the  automation 
process  must  utilize  data  from  a  harmonized 
product  data  model,  and  be  available  for  use 
throughout  the  entire  product  life  cycle. 
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Figure  3.5-2 ^  Life  Cycle  Testing 


types  of  technology  (i.e.  Digital,  Analog, 
Mechanical  etc.),  and  also  all  levels  of  assembly 
(i.e.  boards,  subsystems  and  systems).  Third, 
the  tools  must  accept  product  data  in  the  form  of 
industry  data  standards  from  CAE/CAD  tools 
whenever  possible.  Finally,  the  tools  must  link 
conceptual  and  detail  design  phases.  This  linking 
process  includes  supporting  both  a  top/down  and 
bottom/up  methodology.  This  linking  process 
will  allow  the  high  level  requirements  for 
testability,  maintenance,  and  diagnostics  to  be 


There  are  five  test  activities  that  should  be 
automated  to  support  Integrated  Diagnostics. 
They  are  as  follows  : 

1 .  A  tool  to  automate  top/down  diagnostic 
allocation  requirements. 

2 .  A  tool  to  develop  diagnostic  strategies 
based  on  functional  dependencies. 

3.  A  tool  that  provides  BIT  insertion,  and 


71 


UNCLASSIFIED 


determines  BIT  effectiveness. 

4 .  A  tool  to  automate  FMECA  (Failure 
Mode  Effects  and  Criticality  Analysis). 

5 .  A  tool  to  automate  TPS  development. 

The  diagnostic  allocation  tool  would  translate 
high  level  operational  and  support  requirements 
into  lower  level  diagnostic  requirements  for  each 
sub  function  of  a  system.  This  process  would 
include  determining  the  fault  detection  and  fault 
isolation  requirements  for  each  sub  function  of  a 
system.  The  diagnostic  allocation  tool  would 
work  with  a  knowledge  base  to  assess  the 
optimal  diagnostic  architecture  for  a  subsystem 
element.  High  level  functional  simulations 
would  be  performed  as  part  of  the  analysis 
process. 

Commercial  tools  exist  today  that  generate 
diagnostic  test  strategies  based  on  functional 
dependencies  of  a  system.  These  tools  allow 
what-if  scenarios  to  be  performed  before  a 
system  is  committed  to  detail  design.  The 
commercial  tools  should  be  integrated  with  the 
other  tools  that  support  Integrated  Diagnostics. 

BIT  analysis  is  the  process  of  determining  the 
effectiveness  of  a  system's  BIT  design 
architecture.  BIT  consists  of  a  combination  of 
hardware  and  software  techniques  that  allow  a 
system  to  monitor  itself.  Typically,  the  hardware 
aspects  of  BIT  are  defined  first,  while  the 
software  BIT  design  occurs  later  in  the  design 
cycle.  The  software  is  more  flexible  and  easier  to 
modify,  therefore  a  tool  should  be  developed  to 
help  analyze  the  overall  effectiveness  of  the 
hardware  BIT  aspects  independent  of  the 
software.  Certain  assumptions  can  be  made 
relating  to  the  functionality  of  the  software.  The 
output  of  this  tool  will  be  a  metric  defining  how 
well  the  BIT  design  can  detect  and  isolate  failures 
in  the  system.  This  tool  would  be  part  of  the 
design  for  test  tool.  As  the  DFT  tool 
recommends  BIT  insertion,  it  will  also  provide  a 
figure  of  merit  as  to  how  effective  the  BIT  would 
be. 

Commercial  tools  are  also  emerging  that  support 


failure  modes  effects  and  criticality  analysis 
(FMECA).  In  the  past  the  FMECA  tool  set  only 
included  support  for  documenting  the  results  of  a 
FMECA  analysis.  Little  support  was  available 
for  actually  defining  the  effects  of  failure  modes 
on  a  system.  New  tools  are  available  today  that 
allow  one  to  model  a  system  at  a  high  level,  and 
graphically  view  the  effects  of  failure  modes. 
These  FMECA  tools  should  be  integrated  with  a 
common  Integrated  Diagnostic  tool  set. 

3.5.3  Challenges 

Standards  are  a  very  imponant  aspect  linking  the 
proposed  test  procedure  solutions  to  the  RASSP 
model  year  concept.  Unfortunately,  not  all 
standards  have  been  approved  as  of  yet,  and  the 
approval  process  for  pending  standards  could 
take  years.  Two  critical  standards  that  need 
approval  are  the  Test  Requirements  Specification 
Language  (TRSL),  and  the  Fault  Dictionary 
Language  (FDL).  In  the  interim,  concepts  can  be 
developed  around  the  proposed  standards  with 
the  assumption  that  the  proposed  standards  will 
become  approved  standards  before  detailed 
implementation  issues  occur.  Working  groups 
such  as  the  Test  Automation  Standards  Group 
will  be  a  key  driving  force  to  make  standards 
such  as  TRSL  and  FDL  a  reality. 

Some  commercial  tools  exist  today  addressing 
system  design  test  procedure  issues.  As  defined 
above,  new  tools  must  be  developed  to  address 
the  requirements  for  testing  within  the  RASSP 
model  year  concept.  These  tools  must  be 
integrated  under  a  common  framework  with 
existing  commercial  tools  to  provide  a  seamless 
tool  environment.  The  challenges  exist  in  the 
CAD  framework  standards.  The  CAD 
Framework  Initiative  (CFI)  is  still  defining  the 
standards  associated  with  interface  standards.  As 
with  the  design  system,  close  monitoring  and 
support  of  CFI  is  required  to  meet  the  challenges 
of  integrating  commercial  tools  with  newly 
developed  tools. 

The  RASSP  model  year  concept  will  be  pushing 
the  latest  technology  upgrades  for  various 
weap>on  systems.  It  is  unlikely  that  ATE  will 
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keep  pace  with  the  latest  technology.  Therefore, 
it  is  essential  to  focus  new  test  procedures  on 
BIT/BITE  to  reduce  the  dependency  on  ATE. 
Interface  standards  for  both  hardware  and 
software  must  be  defined  and  implemented  to 
support  the  communication  of  BIT  architectures 
with  existing  ATE  in  the  factory,  depot,  and 
field.  The  Air  Force  has  been  addressing  this 
standard  interface  requirement  through  the  ABET 
(Ada  Based  Environment  For  Test)  program. 

The  increased  emphasis  on  BIT/BITE  will 
generate  new  challenges.  Many  weapon  systems 
today  experience  a  high  frequency  of  false  alarms 
related  to  BIT.  A  study  was  conducted  on  the 
Bl-A  which  had  the  objective  of  identifying  and 
classifying  the  reasons  for  BIT  false  alarms.  The 
report  (ASD-TR-8 1-5203)  summarized  that  of 
1704  test  flight  failures,  919  were  classified  as 
false  alarms.  New  initiatives  have  already 
started  to  reduce  the  degree  of  false  alarms 
associated  with  BIT.  Raytheon  Co.  recently  won 
an  award  from  Rome  Labs  to  address  false  alarm 
filtering  using  neural  network  principles. 

3.5.4  Feasibility 

The  test  subcommittee  of  the  IEEE  Computer 
Society  Design  Automation  Standards 
Subcommittee  (DASS),  and  the  Test  Automation 
Standards  Group  (TASG)  have  been 
aggressively  pursuing  the  standardization  of 
TRSL,  and  FTDL.  Close  contact  with  these 
standardization  groups  is  essential  to  stay  abreast 
of  the  latest  standards  issues  so  that  they  can  be 
applied  to  the  RASSP  model  year  concept. 

The  Air  Force  has  initiated  an  on-going  effort  to 
standardize  on  the  Ada  programming  language  to 
develop  test  program  sets  (TPS).  In  1989,  the 
IEEE  Standards  Coordinating  Committee  20 
(SCC20)  approved  using  Ada  as  a  central  focus 
for  the  proposed  ABET  .  standard.  The 
proposed  ABET  standard  scope  is  to  define  a 
standard  Ada  based  environment  which  uses 
other  standards  relating  to  design,  test  and 
maintenance  activities.  The  Air  Force  ABET 
program  is  a  four  phase  five  year  program  to 
define  and  implement  ABET.  The  outcome  of 


ABET  can  be  directly  applied  to  the  issues  of 
providing  a  common  test  environment  for  the 
factory,  depot,  and  field. 

The  ManTech  Directorate  at  Wright  Patterson 
AFB  will  be  funding  a  program  called  VTEST 
(Viitual  Test)  in  1993.  The  objective  of  VTEST 
is  to  develop  an  environment  that  allows  a  5;1 
reduction  in  test  program  development  and  re¬ 
target  costs.  The  "core"  standards  that  come  out 
of  ABET  will  be  applied  to  VTEST.  The 
commercial  tools  that  are  delivered  for  the 
VTEST  program  should  be  incorporated  as  pan 
of  the  RASSP  test  procedures  environment. 

Rome  labs  funded  a  program  called  TISSS 
(Tester  Independent  Support  Software  System). 
The  TISSS  program  proved  that  the  use  of  CAD 
and  tester  independent  electronic  product  data  can 
be  used  for  the  capture  and  use  of  electronic 
design  and  test  information  for  the  automatic 
generation  of  TPS's  and  test  specifications.  The 
TISSS  tools  were  successfully  applied  to  an  ATF 
LRM.  Technology  associated  with  the  TISSS 
IN-STEP  post  processor  should  be  investigated 
for  applicability  to  RASSP. 

Raytheon  has  a  pending  proposal  relating  to  the 
use  of  BIT.  In  response  to  the  DARPA  ASEM 
BAA  92-09,  Raytheon  submitted  a  proposal 
called  Intelligent  Test  Controller.  This  proposal 
addresses  the  requirement  of  inserting  BIT  early 
in  the  product  life  cycle.  High  level  test 
requirements  specifying  test  intent  independent  of 
technology  is  captured.  The  tool  reads  the  test 
requirements,  a  knowledge  base  of  BIT 
structures,  a  functional  description  of  the  UUT, 
and  automatically  synthesizes  a  test  controller 
description  in  AdaorVHDL. 

The  commercial  industry  has  been  making 
progress  in  the  area  of  TPS  development. 
Teradyne  has  developed  and  demonstrated 
software  that  transports  TPS's  from  one 
commercial  ATE  to  another.  The  demonstration 
was  based  on  translating  Genrad  179x  TPS's  to 
the  Teradyne  L-series  ATE.  The  translation 
system  included  both  the  translation  of  test 
programs  and  test  fixf  .res.  The  fixture 
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translation  was  based  on  designing  a  standard 
interface  fixture  that  would  mate  with  the  Genrad 
fixtures.  The  concept  of  developing  standard 
"interface  fixtures"  should  be  investigated  further 
for  applicability  to  RASSP. 

Commercial  CAE  companies  such  as  Synopsys 
have  tools  that  automatically  insen  BIT  structures 
into  a  component  represented  in  VHDL.  TSSI  is 
developing  software  that  will  both  read  and  write 
the  IEEE  WAVES  standard. 

Universities  such  as  Virginia  Tech,  and  USC  are 
working  on  software  that  address  testability  at 
higher  levels  of  abstraction.  Virginia  Tech,  has 
software  that  supports  the  concept  of  functional 


fault  simulation  based  on  VHDL  behavioral 
descriptions.  This  functional  fault  simulation 
software  is  consistent  with  the  overall  direction 
of  analyzing  testability  early  during  preliminary 
design. 

The  government,  commercial  industry,  and  the 
universities  have  been  making  advances  in 
broadening  the  support  for  test.  The  RASSP 
program  can  take  advantage  of  the  latest 
technology,  and  apply  it  to  meet  the  objective  of 
designing  test  capabilities  into  a  system,  to 
support  the  concept  of  rapid  insertion  of  cost 
effective  hardware/software  upgrades. 
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3.6  Eoulpment  Requirements 

The  RASSP  program  demands  a  manufacturing 
foundation  that  can  provide  the  highest 
manufacturing  flexibility,  lowest  cost  per  unit, 
and  most  rapid  response  time.  While  the  tools 
and  methodologies  to  achieve  these  objectives 
differ  depending  on  assembly  level,  all  suppliers 
need  a  strong  manufacturing  system  support 
structure  to  drive  the  factory.  The  ability  to 
provide  rapid  response  and  low  cost  is  a  function 
of  the  systems  at  the  manufacturing  site. 
Computer  Integrated  Manufacturing  (CIM) 
systems  have  promised  to  enable  a  factory  to 
operate  profitably  at  an  order  quantity  of  one. 
While  this  promise  has  yet  to  be  achieved, 
significant  strides  have  been  made  in  linking 
factory  floor  equipment  to  above  floor  control 
systems. 

The  RASSP  industrial  base  must  embrace 
flexible  manufacturing  systems  that  can  support 
rapid  turnaround  and  low  volume  production. 
These  systems  must  be  scalable  to  higher 
production  rates  on  demand.  These  systems  must 
be  based  around  a  set  of  standard  tooling  on 
programmable  equipment. 

Typically,  such  production  lines  are  based  on  a 
standard  family  of  parts.  Associated  with  this 
family  is  a  set  of  operations  and  resources  that 
can  fabricate  the  variety  of  parts  that  belong  to  the 
family.  Part  families  are  conceived  through  the 
identification  of  parts  that  are  characterized  by  a 
common  set  of  attributes.  Given  the  common 
product/process  attributes,  a  production  line  is 
constructed  to  support  production  of  the  family. 
A  communication  and  information  infrastructure 
integrates  equipment  programs,  process  control. 


equipment  status,  and  WIP  information.  Volume 
is  achieved  through  the  ability  to  produce  an 
family  member  without  extensive  set  up.  The 
equipment  is  driven  by  computer  programs 
generated  from  CAD  databases.  By  increasing 
the  programmability  of  the  equipment, 
standardizing  on  tooling,  and  integrating  the 
information  flow,  low  volume  production  can  be 
economically  achieved 

3.6.1  Assembly  Equipment 

Automatic  assembly  equipment  for  through  hole 
component  types  include  interfaces  for  process 
monitoring  and  off-line  programming.  Surface 
mount  components  are  assembled  by  "pick  and 
place"  assembly  machines.  These  work  well 
down  to  25  mil  pitch.  Pick  and  place  technology 
typically  relies  on  vision-assisted  centering  and 
squaring  of  components.  Pick  and  place 
technology  is  fairly  slow  and  will  create 
production  bottlenecks  as  device  counts  grow 
and  density  increases.  Development  is  needed  in 
faster,  more  accurate  placement  of  devices. 

As  packaging  moves  toward  ultrafine  pitch 
technology  such  as  TAB  and  Flip  Chip,  the 
assembly  equipment  becomes  more  specialized. 
The  mixing  of  technology  would  lead  to 
requirements  for  a  number  of  different  pieces  of 
equipment. 

Ultrafine  pitch  components  and  denser  modules 
are  forcing  rework  and  repair  techniques  to 
become  more  sophisticated.  Semi-automated 
systems  deploying  vision  systems,  special 
lighting,  microscopes,  and  electronic  displays  are 
evolving. 

Sensors  and  process  control  mechanisms  are 
required  to  provide  production  and  process  status 
information  links. 
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3.7  Facility  Requirements 

To  accomplish  study  phase  objectives,  the  team 
examined  the  capabilities  of  easily  accessible 
facilities  with  state  of  the  art  capabilities.  The 
facility  in  Portsmouth  RI  which  supplies  a  major 
portion  of  the  Navy's  Standard  Electronic 
Modules  (SEM)  has  a  unique  capability  such  that 
it  can  adapt  to  high  density  MCM  based  SEM  and 
3D  stacking  modules.  The  facility  in  Lowell, 
MA  supplies  Hybrid  Electronic  Assemblies. 
Each  will  be  described  below.  The  team  also 
investigated  other  potential  RASSP  suppliers 
including  the  Microelectronics  Manufacturing 
Science  and  Technology  (MMST)  cluster  tool 
facility  of  Texas  Instruments. 

3.7.1  Raytheon  SEM*E  Capabilities 

The  manufacturing  facility  at  Raytheon 
Submarine  Signal  Division  (SSD),  Portsmouth 
RI  is  fully  equipped  to  produce  complete 
electronic  systems  including  circuit  card 
assemblies.  Raytheon  SSD  manufacturing 
facilities  encompass  131,000  square  feet  that 
includes  a  state-of-the-art  material  center,  all  of 
the  production  level  processes  for  through  hole 
and  surface  mount  technology  circuit  card 
assemblies,  ceramic  thick  film  multi-layer 
interconnect  board  manufacturing,  cable  and 
harness  fabrication,  electromechanical  assembly 
of  all  sizes,  a  versatile  machine  shop,  and 
transducer  manufacturing. 

Specifically  regarding  circuit  card  assembly 
manufacturing,  Raytheon  SSD  has  in  place 
proven  equipment  and  processes  for  component 
placement,  mass  reflow  and  wave  soldering, 
automated  conformal  coating  and  sophisticated 
test  capability  for  the  existing  product  lines. 

For  the  past  17  years,  Raytheon  has  been  actively 
involved  in  the  development,  system  packaging 
and  mass  production  for  the  Standard  Electronic 
Module  (SEM)  Program.  Presently  Raytheon  is 
certified  for  the  production  of  SEM-A,-B,-D  and 
E  boards  by  the  Naval  Weapons  Suppon  Center 
(NWSC),  Crane.  In  addition,  the  Copper  Thick 


Him  Multi-Layer  Ceramic  Boards  facility  for  the 
SEM  Program  is  also  certified  by  NWSC. 

The  facility  has  historically  worked  very  closely 
with  the  Naval  Avionics  Center  (NAC)  and  the 
Naval  Weapons  Suppon  Center  (NWSC)  with 
their  board  documents.  In  support  of 
involvement  with  both  government  and  industry, 
we  are  the  lead  IEEE  participant  associated  with 
1101.3,  a  conduction-cooled  Eurocard  designed 
for  avionics  environments,  and  with  1101.4,  a 
SEM-E  size  MIL  module.  Raytheon  is  the  editor 
for  the  1 101.4  specification  and  the  architect  for 
1101.3  specification.  We  have  supplied  design 
suppon  and  product  to  customers,  successfully 
demonstrating  capability  for  technology 
exchange. 

Raytheon  developed  a  packaging  system  jointly 
with  NWSC  for  an  open  architecture  system  now 
operational  on  the  AN/BSY-1  combat  system  for 
submarines.  Developed  to  meet  the  requirements 
of  the  Navy  Standard  Hardware  Acquisition  and 
Reliability  Program,  the  board  set  is  the 
forerunner  for  concepts  now  specified  in  both  the 
Joint  Integrated  Avionics  Working  Group 
(JIAWG)  and  the  Next  Generation  Computer 
Resources  (NGCR)  programs.  The  AN/BSY-1 
program  provided  Raytheon  with  exposure  to  the 
problems  of  inter-operability,  testability  and 
exchangeability  as  our  standard  board  set  was 
used  on  a  major  platform  by  multiple  vendors  in 
various  configurations  in  an  integrated  system. 
For  those  vendors,  we  manufactured  a  core  set  of 
boards  (CPU,  global  memory  and  I/O), 
supplemented  by  digital  signal  processors,  A/D 
and  D/A  converters,  and  analog  signal 
conditioners.  These  boards,  SEM-D,  are  only 
slightly  smaller  than  SEM-E.  To  date,  the 
number  of  these  SEM-D  boards  delivered  to  the 
Navy  and  maintained  in  the  operational  sonar 
system  exceeds  35,000. 

Raytheon's  board  facility  has  been  certified  for 
SEM-E  by  the  Naval  Weapons  Support  Center, 
Crane  (NWSCC)  to  meet  the  requirements  of 
QAA  programs  as  defined  in  MIL-M-28787D. 
This  facility  was  staned  in  1985  to  accelerate 
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ceramic  MIB  technology  and  product  availability. 
Today,  it  continues  to  manufacttire  ceramic  and 
polyimide  SEM  boards  for  the  Navy's  AN/BSY- 
1  program.  Recent  advances  in  solder/flex 
application,  conformal  coat  technologies  and 
enhanced  test  diagnostics  are  examples  which 
have  led  to  the  improved  yields. 

3.7.2  Raytheon  Lowell  Capabilities 

Raytheon  Missile  System's  Division  Lowell 
Manufacturing  Plant  specializes  in  hybrid  parts. 
The  plant  consists  of  17,000+  square  feet  of 
Class  100,000  Clean  room  floor  space.  The 
facility  manufactures  over  166  hybrid  part 
numbers  of  mixed  types  including  analog, 
digital,  high  frequency  and  microstrip.  These 
hybrids  represent  5  programs  including 
AMRAAM,  Phoenix,  Stinger,  Sidewinder  and 
Sparrow  (7-P).  Raytheon's  Lowell  facility  has 
proven  process  capabilities  for  0.7,  1.0,  2.0  mil 
Gold  Ball  Bonding,  0.7,  1.0  mil  Gold  Wedge 
Bonding,  3  mil,  10  mil,  20  mil  Gold  Ribbon 
Bonding  and  Coining  thick  film  substrates. 
Materials  types  include  Thick  Film  Networks, 
Thin  Film  Networks,  Duroid  Networks,  Silicon 
Devices,  Gallium  Arsenide  devices  and  Quartz 
Devices. 

The  Lowell  plant  assembles  hybrids  using  their 
extensive  assembly  capabilities.  These 
capabilities  include  semi-automatic/  automatic 
attachment  of  die  and  chip  components,  semi¬ 
automatic/  automatic  application  of  component 
attach  adhesives,  and  manual  attachment  of 
eutectic  devices.  Hybrid  packages  and 
assemblies  are  laser  marked  using  a  Control 
Systems  Laser.  There  is  an  Autoclave  for 
pressurized  curing  of  epoxy  preforms  which  are 
used  to  attach  microstripline  circuits  to  packages. 
Rework  capabilities  consist  of  removal  and 
replacement  of  epoxy  attached  devices/substrates, 
removal  and  replacement  of  eutectically  attached 
devices,  and  four  delidding  systems. 
Additionally,  wirebonding  capabilities  include 
both  automatic  and  manual  ball  and  wedge 
bonders. 

Lowell  inspection  capabilities  include  hi/low 


power  inspection,  environmental  screening,  leak 
testing,  bum-in,  and  in-circuit  test.  Hi/low 
power  inspection  consists  of  manual  bond  pull 
and  semi-automatic  point-point  wiring 
inspection.  Temperature  cycling,  acceleration 
and  FIND  testing  provide  full  environmental 
screening.  Capabilities  also  include  liquid  and  air 
bum-in.  Helium  and  Krypton  85  fine  and  gross 
leak  testing,  and  in-circuit  test  with  a  board  watch 
system  for  troubleshooting  and  rework.  Testing 
capabilities  at  Lowell  includes  a  manual/semi¬ 
automatic  process  for  tuning  hi-frequency  and 
microstrip  hybrids.  Active  and  ratio  laser 
trimming  of  resistors,  and  ATE  for  functional 
test. 

The  Lowell  plant  continues  to  implement 
advanced  manufacturing  systems  that  result  in 
higher  efficiency  and  better  quality  products.  In 
the  hybrid  area,  shop  floor  paperless  display 
systems  are  being  installed  to  provide  assembly 
operators  with  color  graphic  assembly 
instmetions.  Over  25%  of  all  process  plans  and 
100%  of  process  specification  reference 
instmetions  have  been  put  on-line.  The  facility 
will  have  displays  on  75%  of  the  assembly 
workstations  by  the  end  of  1992.  The  Product 
Assurance  Inspection  Reporting  System  (PAIRS) 
is  a  mainframe  based  statistical  quality  control 
system  that  is  used  to  track  quality  trends  and 
initiated  corrective  action  cycles  when  required. 
PAIRS  is  complemented  by  on-line  statistical 
process  controls  include  epoxy  screen  printing, 
wirebonding,  component  attach  and  sealing. 
There  is  a  wanding/bar  code  system  in  place  for 
the  automatic  tracing  of  work-in-process  and  a 
vertical  carousel  storage  of  hybrid  part  inventory 
for  rapid  kitting. 

3.7.3  PWB  Fabrication  and 
Assembly  Services 

There  is  a  broad  base  of  PWB  fabrication  and 
assembly  contract  manufacturers.  Fabricated 
PWBs  that  meet  Mil  55110  qualifications  can  be 
turned  around  in  generally  48-72  hours  for  a 
multilayer  epoxy  glass  substrate.  PWB 
fabricators  rely  on  Gerber  and  drill  hole  data 
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product  data,  as  well  as,  customer  data  such  as 
quantity  and  schedule.  Electronic  transfer  of 
product  data  is  typical.  In  the  PWB  assembly 
area  quick  turn  around  is  also  offered  as  well  as 
full  service  capabilities.  Product  data  exchange 
includes  drawings,  CAD  databases,  pans  list, 
and  test  vectors. 

3.7.4  Cluster  Tool  Facilities 

Cluster  tool  based  facilities  offer  the  ability  to 
provide  low  volume  access  to  semiconductor 
capabilities.  The  concept  of  the  cluster  tool 
facility  is  a  modular  factory  with  automated 
processing  where  the  cleanroom  is  housed  within 
the  equipment  and  transpon  mechanisms  are 
vacuum  cassettes  that  house  the  wafers.  Within 
tools,  wafer  move  via  robot  and  are  processed 
one  at  a  time.  Sensors  and  expen  systems 
provide  process  control  and  status  information. 
The  tools  are  linked  together  in  the  factory  by  a 
computer  integrated  manufacturing  system  that 
provides  recipe  management,  equipment  status, 
.  ..J  work-in-process  status.  The  cluster  tool 


approach  provides  scalability  to  higher  volume 
production.  The  key  to  the  system  is  that  low 
volume  production  can  be  economically  achieved 
and  growth  to  higher  level  of  productions  is 
feasible.  There  is  a  cost  trade-off  with  dedicated 
lines  at  high  volume  rates.  The  footnote 
reference'  provides  a  summary  of  processes  and 
cost  models  for  cluster  tool  fabrication  lines.. 

3.7.5  RASSP  Sources 

Despite  the  in-house  facilities  available  at  four 
divisions  and  seven  manufacturing  plants, 
several  weapon  systems  produced  by  Raytheon 
have  a  major  portion  of  their  components 
purchased  and  manufactured  outside.  A  major 
portion  of  the  country's  industrial  fabrication 
facilities  have  been  used.  For  RASSP,  only  the 
outside  industrial  resource  will  be  used  in  the 
development  of  the  demonstration  units.  Table 
3.7-1  lists  "outside"  MCM  suppliers  which  could 
be  involved  in  the  fabrication  of  RASSP 
processors. 
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Parameters 

Companies 

Technical 
Contact 
(Sales  Contact) 

Technology 
Type 
MCM-C, 
MCM-L,  MCM- 
D,  MCM-D/C, 
MCM-Si 

HDI  Base 
Substrate 
(Max.  Size) 

Chip  Inter¬ 
connection 
Options 

ALCOA 

16868  \  ia  Del  Campo  CT 
San  Diego,  CA  92127 

Len  Schaper 
(619)451-5563 
(Phil  Scott) 

MCM-D 

Alumina, 
Silicon 
[4.0  X  4.01 

Wirebond 

Tab 

Flip  Chip  (NJ) 

ALGOREX 

45  Adams  Ave. 

Hauppauge,  NY  11788 

Bill  Ciechenowski 
(516)434-9400 
X127 
(Charles 
Sutherland) 
(617)235-2330 

MCM-C 

Ceramic,  Metal 

Wirebond 

Tab 

AT&T 

N.  Andover.  MA 

George  Trudel 
(508)  960-4558 

MCM-D 

Alumina 
[4.0  X  3.251 

Wirebond 

Tab 

Flip  Chip 

DEC  (MMS) 

10  Tara  Boulevard 

Nashua,  NH  03062 

Jim  McElroy 
(603)884-0728 

MCM-D 

Alumina 

Wirebond 

Tab 

GE 

Schenectady,  NY 

Charles  Becker 
(518)382-5472 
(W.R.  Broyles) 
(518)337-5835 

MCM-D 
(Chips  First) 

Alumina, 
Silicon.  Metal 
[4.0  X  4.01 

Internal  To 
Structure 

HUGHES 

Newport  Beach,  CA 

Richard  Himmel 
(714)759-2843 

MCM-D 

Alumina,  AIN 
Silicon 
[3.8  X  3.81 

Wirebond 

Tab 

Flip  Chip 

IBIDEN 

1270  Oakland  Paikway 
Suni;yvale,  CA  94086 

RM.  206,  Japan 

SataroITO 
(408)735-7755 
(Rich  Puchniak) 
(508)  526-1211 

MCM-D 

MCM-D/C 

Aluminum 
Nitride  (AIN) 

[^  0  X  4.01  * 
[2.0  X  2.01  ** 

Wirebond 

Tab 

IBM 

1580  Route  52 

Dept.  42W  Bldg.  514 
Hopewell  June.,  NY  12533 

Ed  Chang 
(914)892-9712 

MCM-D 

MCM-D/C 

Glass  Ceramic 
[6.0  X  6.01 

Flip  Chip 

ISA 

600  West  Cummings  Park 
Suite  6000 

Woburn,  MA  01801 

Dr.  James  Kohl 
(617)937-0177  X30 

MCM-D 
(Chips  First) 

Alumina 
[2.0  X  2.01 

Internal  To 
Structure 

KYOCERA 

San  Diego,  CA 

Richard  Gigliano 
(619)576-2770 

mc:m-d 

MCM-D/C 

Alumina 
[4.0  X  4.01 

Wirebond 

Tab  Flip  Chip 

Figure  3.7-1,  MCM  Suppliers 
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Parameters 

Companies 

Technical 
Contact 
(Sales  Contact) 

Technology 
Type 
MCM-C, 
MCM-L,  MCM- 
D.  MCM-D/C, 
MCM-Si 

HDI  Base 
Substrate 
(Max.  Size) 

Chip  Inter¬ 
connection 
Options 

MICRO  SUB.  INC. 
547-D  Constitution  Ave. 
Camarillo,  CA  93010 

Dr.  Ram  Panicker 
(805)482-2006 

MCM-D 

Alumina 
[6.0  X  6.0] 

Wirebond 

Tab 

Flip  Chip 

N-CHIP 

1971  N.  Capitol  Ave. 

San  Jose,  CA 

Bruce  McWilliams 
(408)945-9991 
(Mark  TruUi) 

MCM-Si 

Silicon 
[3.4  X  3.4] 

Wirebond 

Flip  Chip 
Tab(FUT) 

NTK 

40  Speen  St. 

Framingham,  MA 

Keiichi  (Keith)  Fujii 
(408)  727-5180 

MCM-D 

MCM-D/C 

Alumina,  AIN 
[6.0  X  6.0] 

Wirebond 

PMC 

Burnaby,  BC 

Canada 

Colin  Harris 
(604)293-6044 

MCM-D 

Silicon 
[2.8  X  2.8] 

Wirebond 

POLYCON 

Tempe,  AZ 

Bob  Devellis 
(602)731-9544 

MCM-D 

Silicon 
[4.1  X4.1] 

Wirebond 

ROCKWELL 

2427  W.  HillcrestDr. 
Newbury  Park,  CA 

Art  Cappon 
(805)375-1295 

MCM-D 

Silicon 
[1.6  X  1.6] 

Wirebond 

ROGERS 

Rogers,  Conn. 

John  Olenick 
(503)774-9605 

MCM-L 

W/R02800 

Aluminum 
[4.0  X  4.0] 

Wirebond 
Tab,  Flip  Chip 

TELEDYNE 

Los  Angeles,  CA 

Ken  Zust 
(213)822-8229 

MCM-D 

Alumina 

Wirebond 

TI/GE  FOUNDRY 

P.O.  Box  660246 

Mail  Station  3137 

Dallas,  Texas  75266 

Bob  Raulerson 
(214)995-4614 
Theresa  Armstrong 
(214)995-7089 

MCM-D 
(Chips  First) 

• 

• 

TI 

13532  N.  Central 
Expressway,  MS  88 

Dallas,  Texas  75266 

Dean  Fruew 
(214)995-6511 

MCM-D 
(Chips  Last) 

Alumina 
[4.0  X  4.0] 

Wirebond 

Tab 

Z-SYSTEM 

3080  Olcott  St. 

P.O.  Box  HOC 

Santa  Clara,  CA 

Jan  Hull 
(408)980-1563 
(Jan  Hull) 
(408)257-9921 

MCM-D 

Silicon 
[2.8  X2.8  To 
4.0X4.0] 

Wirebond 

Figure  3.7-1  Continued,  MCM  Suppliers 
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3.8  Database 
3.8.1  Objectives 

In  order  to  support  the  goals  of  model  year 
concept,  a  'seamless'  data  model  that  will 
integrate  the  functional  areas  of  design, 
manufacture  and  logistics  must  be  defined. 
Through  the  use  of  this  seamless  data  model, 
product  quality  can  be  improved,  and  hardware 
and  software  product  costs  can  be  reduced. 
Integration  of  design,  manufacturing  and 
logistics  data  will  provide  critical  cross-discipline 
information  in  an  easy  to  access,  timely  manner. 
Using  an  integrated  database,  actual  test  data 
collected  from  manufacturing  and  logistics 
Junctions  can  be  incorporated  into  the  design 
process  to  enable  design! manufacturability  and 
designisupportability  trade-offs.  Further, 
comparing  actual  test  data  with  simulated  test  data 
enables  tuning  of  simulation  models,  leading  to 
more  accurate  predictions.  Both  of  these 
examples  demonstrate  design  for 


mamrfactwrabilityisupportability  by  utilizing  the 
integrated  database  to  supply  manufacturing  and 
test  data  to  design. 

3.8.2  Data  Integration  Soiution 

The  RASSP  database  solution  relies  on  a  'Virtual 
Product  Model'  that  supports  the  integration  of 
physically  separate,  existing  data  (files,  relational 
databases,  etc.)  through  the  definition  of  a 
mapping  between  disciplines.  Domain 
databases,  such  as  the  MIL-STD  1388-2B 
compliant  logistics  database,  existing  CAD 
databases,  etc.,  will  be  logically  married. 
Relationships  will  be  represented  through  object- 
oriented  classes  and  procedures  utilizing  the 
Information  Resource  Dictionary  Standard 
(IRDS)  for  data  modeling.  Use  of  an  object- 
oriented  definition  will  allow  data  model 
extendibility  and  serve  as  a  foundation  for  the 
RASSP  design  system.  Figure  3.8-1  illustrates 
the  multi-disciplines  and  their  relationships. 

In  addition  to  the  functional  domains  of  design, 
manufacturing  and  logistics,  program 


Design: 

e.g.  technology  data 
test  data 

performance  data 
historical  data 
R&M  data 


design  entities  ->  processes— • 


design  entities 
log  support 


Manufacturing: 
e.g.  yield 
cost 

supplier  capability 


process  yteias  ->  design 
parameters 


field  experience  -> 
lesign  trade-offs 


Logisitcs: 
e.g.  reliability 
ontime 
deployment 
board  layers 
w  lines  of  code 


ai  i  demand 
(spares) 


Figure  3.8-1,  Domains  to  be  Integrated 
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management  data  such  as  schedule,  cost,  and  risk 
factors  will  be  collected  and  integrated  with 
domain  databases,  allowing  model  year  trade-off 
decisions  to  be  quantified. 

3.8.2.1  Data  Model 

The  RASSP  model  year  concept  requires  that  the 
dynamics  between  design  and  activities  that  are 
typically  downstream  (i.e.,  manufacturing, 
logistics)  be  defined.  Design  decisions  would  be 
better  understood  with  respect  to  life  cycle  cost  if 
parameters  such  as  manufacturing  capabilities 
were  available  for  consideration  in  trade-off 
analysis. 

A  mapping  that  will  identify  the  relationship 
between  the  domains  of  design,  manufacture  and 


Design  and  Manufacturing 

Raytheon  has  been  researching  the  relationships 
between  design  and  manufacturing  for  a  number 
of  years.  In  our  transition  to  production 
software,  printed  wiring  board  design  parameters 
are  utilized  to  generate  production  packages,  such 
as  automated  process  plans.  In  our  concurrent 
engineering  workstation  for  board  design, 
manufacturing  parameters  such  as  machining 
capabilities,  cost  and  yield  are  quantified  to 
determine  manufacturing  optimization.  Further 
experience  with  MMIC  technology  supported 
research  in  the  link  between  process  and  design 
success.  Actual  data  is  routinely  examined, 
extrapolated  and  incorporated  into  more  accurate 
design  models.  With  expertise  in  this  area,  it  is 


TO: 

Design 

Manufacturing 

Logistics 

FROM: 

(organized  by  physical 
features) 

(organized  by  manufacturing 
builds  and  operations) 

(organized  by  field  actions 
and  events) 

Design 

map  design  parameters  to 
manufacturing  processes 

map  design  parameters  to 
logistics  support  actions 

MFG'ing 

BHUSB 

Logistics 

map  field  experiences  to 
design  parameters 

TABLE  3.8-2,  MATRIX  OF  DOMAIN  RELATIONSHIPS 


logistics  must  be  determined.  Each  domain  is 
governed  by  a  different  classification  and 
organization  of  data  based  on  use.  Similar  to  the 
process  and  product  views  traditionally 
espoused,  the  design  domain  is  organized  by 
physical  features  often  correlated  to  work 
breakdown  structure.  Manufacturing  is  governed 
by  process,  where  data  tends  to  be  organized  by 
manufacturing  builds  and  operations.  Finally, 
field  support  organizes  data  by  field  actions  and 
events.  A  well  thought  out  mapping  will 
determine  the  translations  among  these  data 
organizations.  Table  3.8-2  defines  the 
translations  necessary  to  support  the  RASSP 
model  year  design  system. 


feasible  that  other  technologies  would  leverage 
this  capability  for  success.  Refinement  of  closely 
correlated  process  parameters  with  design 
success  should  continue. 

Design  and  Loeistics 

The  ability  to  utilize  logistics  data  to  support 
design  for  supportability  will  largely  depend  on 
research  into  design  parameters  and  their  effect 
on  field  support.  A  1992  Raytheon  proposal 
submitted  to  DICE  Phase  5  (Logistics  Analysis 
with  Concurrent  Engineering)  explores  the 
design  entities  to  logistics  support  mapping. 
This  area  requires  continued  research. 

Finally,  further  research  must  occur  in  the 
design/manufacturability  versus 
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dcsign/supponability  balance,  which  may  have 
conflicting  requirements.  For  example,  a 
technology  may  be  selected  due  to  an  ability  to 
manufacture  that  technology  with  low 
manufacturing  costs  but  may  not  be  the  most  cost 
effective  line  replaceable  unit,  incurring  large 
support  costs. 

Once  the  relationships  among  domains  are 
determined,  the  relationship  must  be  defined 
through  the  use  of  integration  technology. 
Applications  in  the  RASSP  design  system  would 
access  the  virtual  product  database  through  a 
standard  Application  Programming  Interface 
(API)  call  to  the  data  dictionary.  Visually,  the 
system  would  be  architected  in  the  style  of  Figure 
3.8-3. 


User  Interface 

Application  Programming  Interface 


Data  Dictionary 


Figure  3.8-3,  Data  Access  Architecture 


Many  activities  in  information  integration  are 
aggressively  being  pursued  on  both  an  academic 
and  industry  level.  DoD  research  initiatives  have 
been  ongoing  since  the  1970’s  with  the  Air  Force 
Information  Integration  Support  System  (I2S2) 


program  through  today  with  the  recent  DICE 
Database  Integration  Platform  For  Concurrent 
Engineering.  Industry  activities  are  also 
prominent,  such  as  the  CALS  Data  Dictionary 
Task  Force.  Further,  Raytheon's  internal 
investigation  of  integration  technologies  in 
implementation  of  the  Raytheon  Integrated 
Technical  Information  Service  (RITIS)  has 
reviewed  several  commercial  products  for 
implementation  of  the  data  dictionary  service. 
These  products  include  integration  technologies 
from  HyperDesk,  GRC,  DEC,  Information 
Builders,  and  Control  Data  Corp..  Products 
were  reviewed  based  on  their  adherence  to  the 
Object  Management  Group  (OMG)  specification, 
which  defines  a  standard  API  to  distributed 
objects  such  as  files,  databases,  and  tools  across 
heterogeneous  hardware  and  software.  The  most 
promising  product  thus  far  has  been  the 
Distributed  Object  Management  System,  an 
object  oriented  data  dictionary  product  from 
HyperDesk.  Distributed  Object  Management 
System  complies  with  the  OMG  API  and 
supports  a  dynamo  invocation  interface  allowing 
applications  to  construct  requests  and  invoke 
them  at  run  time.  This  dynamic  distributed 
environment  enhances  the  scaleability  and 
maximized  performance.  The  HyperDesk 
Commercial  Off  The  Shelf  (COTS)  product 
would  be  recommended  for  further  investigation 
for  data  model  implementation. 

3.8.2.2  Standards 

Standards  play  a  significant  role  in  the  integration 
of  data  both  within  a  single  domain  and  among 
domains.  Standards  will  be  used  to  integrate  and 
exchange  data  where  available.  The  Standard  for 
the  Exchange  of  Product  Model  Data  (STEP)  is 
an  international  standardization  activity,  ISO 
10303,  to  provide  a  digital  form  for  representing 
and  communicating  product  data  throughout  the 
life  cycle  of  a  product,  independently  ft’om  any 
application  software  that  may  be  used  to  process 
it.  STEP  will  be  a  multi-version  standard, 
released  as  "parts"  are  defined.  The  first  version 
of  STEP  is  anticipated  in  Q4  1992  to  include  an 
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application  protocol  for  3D  Configuration 
Controlled  Design  (AP  203).  Additional 
application  protocols  are  being  addressed  by 
numerous  industry  and  government  funded 
activities,  including  the  functional  areas  of 
Explicit  Drafting,  Associative  Drafting, 
Mechanical  Design  using  Boundary 
Representation. 

As  RASSP  needs  are  evaluated,  in  the  case  that 
no  standard  expression  for  data  exists,  standards 
activities  will  be  recommended.  For  example, 
the  lack  of  a  standard  description  of 
manufacturing  models  will  hinder  the  goal  of 
virtual  manufacturing  and  brokering  concepts.  A 
STEP  activity  should  be  sponsored  to  address 
this  area. 

As  databases  migrate  to  STEP,  the  issue  of 
integrating  dissimilar  data  formats  through  the 
use  of  costly  translators  will  diminish.  The 
adoption  of  the  STEP  Data  Access  Interface 
(SDAI),  now  in  committee,  will  standardize  the 
interaction  between  applications  and  the  STEP 
data  model,  thus  simplifying  the  overall 
architecture  of  the  design  systems  data  access 
mechanism.  Acceleration  of  the  STEP  standard 
both  in  the  standard  definition  and  in 


implementation  of  the  standard  will  simplify  the 
database  integration  task. 

Tools  for  developing  and  supporting  STEP 
applications  are  now  available  commercially. 
There  are  at  least  five  corporations  now  offering 
products  or  prototypes  supponing  STEP  data 
model  generation  from  EXPRESS.  Raytheon 
has  established  ties  with  the  two  United  States 
companies:  STEP  TOOLS,  Inc.,  and  Digital 
Equipment  Corp.  These  relationships  will  play  a 
key  role  in  the  implementation  of  the  design 
system  database  solution. 

While  the  STEP  standard  matures,  dependency 
on  alternative,  existing  standards  and 
harmonization  efforts  will  be  paramount  for  an 
implementation  maximizing  portability  and 
minimizing  maintenance.  An  in  depth 
understanding  of  the  standards  and  their 
availability  will  be  an  ongoing  challenge  in  the 
development  of  the  RASSP  design  system. 
Figure  3.8-4  depicts  a  list  of  standards,  current 
and  future,  that  have  been  identified  during  the 
RASSP  study  phase  as  critical  to  implementation. 
The  standards  cover  electrical  and  mechanical 
design,  test,  library  formats,  and  technical  data 
packages,  as  well  as  standard  ways  to 
communicate. 
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jblems  in  using  standards  do  exist.  One 
nmon  problem  results  from  interpretation.  To 
i  .  jstrate,  consider  the  VHDL  standard,  where  a 
single  design  can  be  represented  in  a  number  of 
ways.  An  attempt  to  address  this  standard 
problem  is  through  the  concept  of  the  STEP 
Application  Protocol  that  defines  the  context  for 
the  data  model.  A  second  limitation  stems  from 
overlap  in  multiple  standards.  In  the  case  of 
VHDL  and  Verilog,  both  standards  can  be  used 
to  represent  the  same  set  of  design  data.  The 
standard  chosen  is  highly  application  dependent. 
Adoption  and  promulgation  of  standards 
represents  yet  another  problem  with  the  use  of 
standards.  Each  of  these  limitations  will  be 
addressed  through  leverage  from  the  industry  and 
DoD  initiatives  in  standard  development  and 
harmonization.  The  following  activities  should 
be  supported: 

IGES/PDES  Organization  (IPO) 

CAD  Framework  Initiative  (CFI) 

PDES/STEP  Application  Protocol  - 
Electronics  ^AP-E) 

IEEE  VHDL  and  EDIF  standardization 
activities 


Computer  Aided  Acquisition  and  Logistics 
Suppon  (CALS)  data  exchange  initiatives 
Microwave  Hardware  Design  Language 
(MHDL)  initiative 
VTEST 

Results  of  TISSS 
PDES,  Inc. 

3.8.3  Libraries 

The  RASSP  model  year  concept  relies  heavily  on 
the  availability  of  libraries  reflecting  both  current 
and  projected  capabilities.  Through  the  use  of 
libraries,  the  concept  of  reusability  can  be 
supported.  An  initiative  within  the  CAD 
Framework  Initiative  (CFI)  concerning 
Component  Information  Representation  (CIR)  is 
striving  to  develop  a  standard  representation  for 
electrical/electronic  component  information 
models  and  libraries.  This  type  of  activity  is 
critical  to  the  success  of  a  library  effort.  Once  a 
standard  library  format  is  adopted,  applications 
accessing  multi-vendor  libraries  of  parts  will 
become  more  prevalent  and  library  development, 
support,  and  maintenance  issues  will  be  relieved 
from  the  RASSP  design  system. 


■uni 

Q4  1992 

1993  -  1997 

20xx 

VHDL 

Verilog 

WAVES 

IGES 

CCnT-G4 

CGM 

SGML 

ANSI  X.  12  EDI 
CH  Pilot  1.0 
(Draft) 

ATLAS 

EDIF 

TEDL 

RDL 

STEP  VI  {AP203, 

Series  40,  Series  100) 
CFI/CIR  Information 
Model  Library 

STEP  V2  { AP204, 
AP205} 

CFI/CIR  Electronic  Data 
Book 

TRSL 

FDL 

CH  2.0 

STEP  Vn  {APxxx,...} 

Figure  3.8-4,  Standards  Timeline 
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Library  solutions  require  a  unique  infrastructure 
to  succeed,  such  as  the  ability  to  ensure  integrity 
and  quality  of  models.  While  library 
management  presents  challenges,  the  availability 
of  libraries  in  a  standard  format  is  critical  to 
support  the  model  year  goal  of  reusability. 

Libraries  are  also  required  to  purposefully  share 
manufacturing  models  with  the  goal  of  virtual 
manufacturing.  In  order  for  a  designer  to 
understand  what  is  feasible  in  model  year, 
manufacturing  models  defining  technology 
capability  must  be  available.  Even  in  the 
paradigm  of  a  brokering  system,  manufacturing 
models  would  be  required  for  accurate  fabrication 
selection.  Research  during  the  RASSP  Study 
Phase  revealed  a  void  in  this  area  that  should  be 
corrected  during  the  Implementation  Phase. 
Clearly,  a  single,  standard,  model  for  all 
manufacturing  technology  is  important  to 
minimize  integration  efforts. 


3.8.4  Risks/Issues/Recommended 
Research 

Availability  and  fidelity  of  manufacture,  test  and 
field  data  under  Model  Year  concept  is  uncertain. 
The  model  year  concept  forces  projection  of 
future  manufacture  and  support  capabilities. 
Alternative  laboratory  methods  to  produce 
accurate  'projected'  (e.g.,  model  year)  models 
must  be  pursued.  To  further  complicate  the 
problem,  as  fewer  systems  are  deployed,  and  the 
trend  is  that  fewer  will  be  manufactured,  the 
availability  of  actual  current  data  will  also 
diminish.  Developing  close  working 
relationships  with  vendors  and  research 
establishments  to  provide  accurate  current  and 
'projected'  logistics  and  manufacturing  data 
would  be  recommended  as  an  activity  for  the 
Implementation  Phase. 

Developing  standard  library  representations  for 
performance  models,  functional  models, 
reliability  models,  manufacturing  process  models 
are  currently  not  being  addressed  under  a  unified 
standards  organization  and  should  be  an  area  of 
investment  under  the  RASSP  program.  Any 
progress  made  in  this  direction  will  add  to  the 
success  of  the  RASSP  program. 
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3.9  Teaming  Arrangements  With 
Other  Organizations 

Teaming  foundations  can  be  established  during 
the  RASSP  contract.  Figure  3.9-1  clarifies  the 
generic  form  of  a  RASSP  program  structure.  In 
this  diagram,  the  terminology  is  as  follows. 

•  ‘Team  Members”  are  partners  in  the  program 
and  contribute  ideas  to  the  program.  They 
are  not  viewed  as  sub-contractors  who  are 
given  a  statement  of  work. 

•  The  ‘Team  Advisory  Board”  are  senior 
representatives  of  the  ‘Team  Members”  who 
meet  on  a  regular  basis  to  advise  the  ‘‘Prime 
Contractor(s)”  of  concerns,  and  their 
resolution. 

•  The  ‘‘Industrial  Review  Board”  is  composed 
of  representatives  from  a  number  of 
organizations  interested  in  influencing  the 
content  and  execution  of  the  RASSP 
prr.*gram.  An  alternative  would  be  to  have  the 
IRB  advise  the  “Program  Manager." 

•  The  “Design  System  Users”  are  interested 
parties  who  will  have  access  to  the  design 
enNironment  which  is  developed  under 
RASSP,  and  will  use  the  software  for  design 
work  or  evaluation. 


Figure  3.9-1,  Teaming  Organization 
Chart 

m  members  represent  developers  within: 

‘  System  Orgaiuzation 
•  CAE/EDA  Industry 


•  MCM/Board/Assembly/IC  Manufacturers 

•  Universities 


Typical  CAx  Vendor  candidates  are  listed  in  the 
following  Tables  for  reference: 


ASC 

VHDL  test  tool  development 

Ascent  Logic 

Requirements  analysis  & 
Traceability 

Cadence 

Developed  commercial 
framework,  and 
commercialized  MMIC  tools 

Cadre 

Developed  commercial 
software  design  tools 

Comdisco 

Developed  commercial  DSP 
tools 

Dasys 

Developing  commercial  system 
partitioning  tool 

DETEX 

Developed  commercial  test 
assessment  tools 

i-Logix 

Developed  commercial  system 
assessment  tools 

Interleaf 

Developed  commercial  product 
for  software  documentation 

Intermetrics 

Language  development 
expertise,  Ada  compiler 
expertise 

JRS 

Processor  and  software 
synthesis  and  cross-compilers 

MCC 

Brokering,  packaging  and  tool 
development 

Mentor 

Developed  commercial 
framework  and  DSP  tools 

Perceptronics 

Process  simulation  tools 

Racal-Redac 

Developed  commercial 
synthesis  and  physical  design 
tools 

Synopsys 

Developed  commercial 
synthesis  tools 

Teradyne 

Commercial  testers  and  tester 
interface  tools 

TABLE  3.9-2,  CAX  VENDOR 
CANDIDATES 
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AT&T 

MC!M  fabrication 

Motorola 

MCM  brokering 

n-Chip 

MCM  technology 

NKT 

MCM  fabrication 

Micro  Modules 
Systems 

MCM  technology 

LSI  Logic 

ASIC  vendor 

n 

ASIC  vendor 

VLSI 

ASIC  vendor 

Board  Mfg 

(Commercial 

TABLE  3.9-3, 

MANUFACTURER 

CANDIDATES 

Univ.  Cincinnati 

System  partitioning 
and  high  level 
synthesis 

Michigan  State 

Logic  partitioning 
and  synthesis 

Mississippi  State 

VHDL  Modeling 

Univ.  Virginia 

VHDL  performance 
modeling,  HW/SW 
co-design 

W.  Virginia 

(Concurrent 
engineering  tools 

TABLE  3.9-4,  UNIVERSITY 
CANDIDATES 


Standards  organizations  provide  a  unifying  effort 
within  the  industry  for  acceptance  of  standards. 
Industry  members  work  together  under  project 
guidance  of  the  organization. 


CALS 

DoD  documentation 
standards 

cn 

(CAD  firamework  database 
access  and  tool  integration 
standards 

EDIF 

Schematic,  netlist,  physical 
design,  and  test  interchange 
standards 

TFFF 

VHDL,  WAVES  standards, 
modules,  busses,  packages 

PDES  Inc. 

Data  modeling  standards, 
STEP  standard  promotion 

VHDL 

International 

VHDL  and  WAVES 
standards 

TABLE  3.9-5,  STANDARDS 
ORGANIZATIONS 


A  typical  example  of  industry  cooperation  and 
joint  activities  can  be  found  in  the  activities  of: 
CAD  FRAMEWORK  INITIATIVE.  Inc. 
403D  W.  BrakerLane 
Suite  550 
Austin,  TX  78759 
Office  (512)  338-3739 
FAX  (512)  338-3853 

Their  experience  to  date  has  involved  the  entire 
EDA  industry  and  has  not  only  helped  in 
obtaining  consensus  on  standards,  but  also  in 
selling  capabilities  to  the  user  community. 
Examples  of  these  projects  are: 

DAC  ‘90  Integration  Project 

•  22  EDA  users  and  vendor  company 
participants 

•  28  applications  sharing  common 
procedural  data  access 

•  9  month  duration  -  completed  on  schedule 
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CFI  1.0  Integration  Project  1991 

•  26  EDA  users  and  vendor  company 
participants 

•  40  applications  sharing  common 
prxxedural  data  access  and  Inter-tool 
communication 

•  9  month  duration  -  completed  on  schedule 

CFI  Pilot  Projects  1992 

•  4  Major  Multi-Company  Projects 

-  HP,  Cadence,  mentor 

-  IBM,  Cadence 

-  Sun,  Viewlogic,  Harris,  Cadence, 
Synopsys 

-  Siemens/Nixdorf,  GMD 

•  CFI  in  role  of  Project  Coordinator 

This  RASSP  foundation  for  a  teaming 
environment  with  DoD  contractors  providing  the 
motivational  system  applications  and  program 
direction  will  initially  create  the  environment  for 
continuing  teams.  A  generic  team  structure 
involving  commercial  ensuing  organizations 
could  take  the  form  of  Figure  3.9-6. 


Figure  3.9-6,  Generic  Team  Structure 


The  broker  can  be  independent  organizations 
matching  industry  capability  to  the  system 
requirements  or  could  be  a  unique  organization 
within  a  major  integrated  circuit  house  or  system 
house.  An  example  of  the  later  is  represented  in 
Figure  3.9-7  where  Motorola  is  acting  as  a 
broker  for  MCM  development  under  subcontract 
from  Raytheon. 


Major  ASIC  vendors  that  are  also  systems  users 
are  particularly  driven  towards  development  of 
team  arrangements  with  the  EDA  industry. 
Texas  Instruments  and  CADENCE,  for  example 
have  a  pannership  to  create  tighter  links  between 
synthesis,  floor  planning  and  layout  tools  and 
users.  TI  will  be  installing  ASIC  workbench  in 
its  worldwide  customer  design  centers.  Its 
engineers  will  also  work  on-site  at  Cadence’s 
San  Jose  facility  to  directly  influence  the 
development  of  an  enhanced  ASIC  Workbench. 

MCM  manufacturers  are  taking  steps  to  bring 
their  capabilities  to  the  system  users  through 
cooperative  ventures  with  CAD  framework 
houses.  As  a  result  Mentor  Graphics 
Corporation  has  announced  an  MCM  design  kit 
for  use  with  MCMs  from  MicroModule  Systems 
(MMS,  in  Cupertino,  California).  The  kit 
includes  documentation,  models  and  technology 
files  with  foundry-specific  information.  It  works 
with  mentor’s  MCM  Station  design  system, 
which  includes  MCM  layout  and  signal-integrity 
analysis. 

These  business  liaisons  will  be  further  promoted 
as  a  result  of  the  RASSP  focus  and  the 
integration  of  CAD  systems  and  manufacturers. 
CAD  and  device  technology  research  can  best  be 
performed  under  Cooperative  Research  and 
Development  Agreements  (CRADA)  with  both 
industry  and  Government  involvement.  DoD 
Laboratories  resources,  expertise  and  project 
management  offer  a  unifying  force  in 
coordinating  multiple  company  activity. 

Consortia  of  the  form  SEMATECH  and  MCC 
offer  an  opportunity  for  shared  resources  and 
specific  projects  resulting  in  shared  benefits.  It 
appears  these  activities  will  continue  with  varying 
degrees  of  success.  While  CRADA ’s  and 
consortia  have  been  primarily  directed  at 
technology  developments  among  competitors  in  a 
specific  business  area,  the  RASSP  focus  is  more 
on  organizing  the  integration  of  unique 
industries  into  viable  business  entities. 
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WEAPON  SYSTEMS 


Figure  3.9-7,  ASIC  Vendor  Acting  As  Broker 
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3.10  Establishment  of  Military 
Sources 

As  the  service  lifetimes  of  defense  electronics 
systems  are  extended,  and  the  procurement  of 
new  systems  is  stretched  out  over  longer  periods 
of  time,  the  already  significant  problem  of 
finding  suppliers  for  some  of  the  key  electronic 
assemblies  of  these  systems  is  expected  to 
worsen.  Figure  3.10-1  illustrates  the  difference 
between  military  and  commercial  microcircuit  life 
cycles.  The  Defense  Logistics  Initiatives 
Division  (DUD)  estimates  that  in  the  next  2  to  5 
years,  approximately  40,000  microcircuit  designs 
will  be  susceptible  to  Diminishing  Maniffacturing 
Sources  (DMS).  The  DUD  estimates  that  the 
average  cost  to  redesign  systems  around  a 
substitute  component  is  between  $150K  and 
$200K  per  instance.  The  RASSP  Design- 
System  and  its  associated  product  data  models 
must  be  adopted  by  the  user  community,  and  be 
compatible  with  as  many  suppliers  as  possible  in 
order  to  minimize  the  impact  of  this  Diminishing 
Manirfacturing  Sources  syndrome. 


Microcircuit  Life  Cycle 


Figure  3.10-1,  Typical  Life  Cycles  For 
A  Family  of  Microcircuits 

Major  Issues 

Establishing  military  sources  for  RASSP 
processors  depends  on  two  major  issues.  First 
of  all,  a  majority  of  defense  contractors  must  be 
adopt  the  RASSP  design-system  and  its 
associated  product  data  models.  This  will  create 


uniformity  of  design,  simulation,  concurrent 
engineering  practices,  and  product  data  models 
among  contractors.  The  collective  effons  of 
RASSP  contractors  will  create  market  demand 
which  —  it  is  hoped  --  will  create  sufficient 
business  incentive  for  sources  to  commit  to 
production  of  RASSP  components  and 
assemblies.  Next,  a  traditional  imposition  of 
military  specifications  cannot  be  maintained. 
Where  possible,  military  specifications  should 
align  more  closely  with  international  and 
commercial  specifications.  This  will  create  dual- 
use  components  and  assemblies  thereby  helping 
to  ensure  their  availability  with  market-pull  from 
both  commercial  and  military  industries. 

Possible  Solutions 

Promulgation  of  the  RASSP  design-system  and 
its  associated  product  data  models  can  be  attained 
by  providing  the  user  community  with  access  and 
involvement  during  the  RASSP  Implementation 
Phase.  Access  and  involvement  are  key  program 
elements  in  attaining  the  goal  of  widespread 
acceptance  and  use.  Access  to  an  operable 
system  throughout  the  course  of  the  development 
allows  hands-on  evaluation  that  benefits  both  the 
RASSP  contractor  and  the  industry  user.  Most 
major  DoD  contractors  and  commercial  system 
houses  invest  each  year  in  tool  evaluation  and  in 
decisions  to  upgrade  their  CAE  resources.  If  the 
program  plan  incorporates  a  phased  development 
where  block  1,  2,  3  are  made  available  to 
industry  at  no  cost,  then  the  opportunities  for 
interest,  use  and  comments  from  the  user 
community  are  greatly  enhanced.  A  system 
could  be  made  available  on  a  network  as  well  as 
on  deliverable  magnetic  medium. 

Block  1,  2,  and  3  must  make  sense  to  the 
RASSP  program  and  to  the  user  community. 
Block  1  would  result  from  the  integration  of 
available  tools  placed  on  available  frameworks 
(Mentor,  Cadence,  Compass).  Tools  and 
standards  would  be  strongly  based  on  VHDL  in 
its  latest  form(s).  Block  2  would  take  advantage 
of  on-going  initiatives  in  commercial  CAE, 
RASSP  funded  advanced  development,  DICE, 
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MADE,  MANTECH  -  that  fit  the  timeline.  Full 
CFI  standards  would  tie  the  system  together. 
Block  3  would  be  the  RASSP  design  system  and 
incorporate  suitable  results  of  research  activity 
and  lessons  learned  from  block  1  and  2. 
Raytheon  anticipates  that  the  user  community 
would  be  proactive  in  their  evaluation  and 
perhaps  propose  additional  projects  for  contract 
consideration.  Maturing  university  research 
would  also  be  transitioned  into  the  block  3 
system.  Block  3  is  obviously  the 
commercialization  baseline  with  the  justifying 
econometrics  being  provided  by  increased  user 
activity  and  system  driven  demonstrations. 
Block  3  addresses  evolving  technology  and 
attempts  to  avoid  the  “generation  gap”  that  often 
exists  between  mature^ighly  efficient  CAE  and 
the  advanced  hardware  technology  it  addresses. 
An  example  of  the  last  issue  might  be  the  CAE 
necessary  to  manage  the  “power  and  parasitics” 
of  several  hundred  megacycle  component 
interconnections. 

Another  might  be  the  ability  to  use  assessment 
tools  within  a  framework  when  “look-ahead”  or 
ad  hoc  CAE  design/analysis  tools  are  used  for 
next  generation  product  models  (next  model  year 
interoperability  issues).  There  are  many  exciting 
possibilities  that  will  come  from  research  of 
design  systems,  languages,  and  system  test  bed 
interfaces  which  can  be  placed  within  the  Block  3 
framework  and  be  allowed  to  mature  even 
beyond  the  RASSP  contract. 

Involvement  requires  a  system  of  selectable 
assets  for  use  by  the  industry.  In  Section  3.0, 
Figure  3.0-2  highlights  the  idea  of  a  multi¬ 
dimensional  design  system  structure. 
Essentially,  the  structure  can  be  viewed  as 
partitioned  (perhaps  virtually)  into  “functions” 
represented  horizontally.  Vertically,  each 
function  has  a  tool  set,  data  types  and  standards 
that  are  not  necessarily  exclusive  to  the  particular 
functional  domain.  The  advantages  of  this 
structure  are  several.  The  military  systems 
house,  the  commercial  systems  house,  or  the 
commercial  CAE  vendor  can  gain  access  to  a 


particular  segment  of  interest  without  resorting  to 
a  complete  resource  commitment.  For  example, 
a  commercial  CAE  developer  may  find  an 
increasing  market  for  assessment  tools  and 
decide  to  focus  their  investment  strategy  in  this 
area.  Many  other  combinations  of  business  and 
development  situations  can  be  envisioned.  The 
system’s  structural  focus  on  standards  and  the 
way  in  which  functions,  tools,  libraries, 
manufacturing  resources  and  test  bed  interfaces 
communicate  throughout  the  design  process 
provides  an  excellent  environment  for  evaluation 
of  upgrades,  and  additional  language  constructs 
and  translators.  This  data  is  also  made  available 
through  networked  bulletin  boards  to  the  user 
community  for  comment  and  to  the  standards 
committees  for  consideration  and  potential  action. 

Military  specifications  need  to  align  more  closely 
with  international  and  commercial  specifications. 
RASSP  can  be  the  ganglion  attached  to  the 
DESC-JEDEC  system,  providing  the  focus  and 
energy  necessary  to  find  a  means  of  promoting 
use  of  commercial  parts,  prioritizing  part 
specifications,  providing  advanced  part  (next 
generation)  data,  and  facilitating  procedural 
systems. 

Use  of  commercial  parts  and  standards  has 
already  begun  with  the  current  emphasis  on 
commercial  off-the-shelf  procurement.  In  the 
past,  DESC  has  purchased  many  commercial 
parts.  However,  most  parts  were  procured 
without  documentation  packages.  Now,  DESC 
officials  are  encouraging  non-government  bodies 
to  develop  standards  for  certain  commercial  parts 
while  DESC  engineers  develop  Commercial  Item 
Descriptions  (CIDs)  to  cover  commercial  parts 
with  no  procurement  documentation.  As  of  July 
'92,  27  CIDs  were  in  progress  at  DESC.  As 
DESC  creates  more  CTDs,  more  commercial  parts 
will  be  available  to  contractors.  The  RASSP 
program  can  accelerate  this  process  by 
identifying  key  commercial  components,  and 
initiating  specification  development  activities  with 
DESC. 

In  addition  to  identifying  key  commercial 
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components,  the  RASSP  program  can  prioritize 
parts  specifications  one  product-generation  ahead 
of  the  current  system.  This  could  be 
accomplished  by  using  high  level  assessment 
tools  and  performance  estimate  data.  Currently, 
DESC  operates  on  a  strict  priority  basis.  They 
handle  complaints  and  user  recommendations  at 
regularly  scheduled  document  revisions.  The 
RASSP  program  can  use  these  existing  channels 
to  setup  specifications  required  by  MODEL 
YEAR  development  cycles. 

DESC's  manufacturer  qualification  provides  a 
more  economical  qualification  system  for 
complex,  small-volume  custom  parts  with  short 
life  cycles  and  rapidly  advancing  technology  that 


requires  extensive  testing.  In  this  qualification 
process,  a  manufacturing  plant's  procedures, 
materials,  controls,  design  rules  and  tests  are 
audited  to  ensure  that  a  component  coming  off 
the  line  will  meet  military  specifications  and 
standards.  DESC’s  Qualifications  Division  has 
55  auditors  who  perform  approximately  520 
manufacturing  plant  and  line  audits  per  year.  In 
the  past  two  years,  DESC  has  assembled  a 
Qualified  Manufacturers  List  (QML)  that  lists  the 
manufacturers  of  advanced  microcircuits  and 
hybrids.  Printed  wiring  boards  will  probably  be 
the  next  category  added  to  the  list.  The  RASSP 
progii.m  can  advise  DESC  on  manufa.  luring 
plants  critical  to  RASSP  processors. 
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3.11  Target  Systems 

Raytheo;  .is  identified  a  broad  range  of  Target 
Systems.  The  tables  throughout  this  section  list 
high-benefit  candidates  in  RADAR,  EW, 
SONAR  and  Missile  applications.  Automatic 
target  recognition  (ATR)  as  a  class  of  problems  is 
categorized  as  a  major  beneficiary  of  the  RASSP 
design  system.  Development  Test  bed  programs 
supporting  ATR  are  identified  and  a  relationship 
between  RASSP  and  these  concurrent  resources 
are  established. 

The  general  discussion  of  advantages  of  using 
RASSP  in  these  systems  includes  the  analyses  of 
acquisition  time  lines.  Typical  acquisition  time 
lines  for  the  process  of  getting  from  concept  to 
development  contract  and  getting  from  contract 


award  to  production  contract  are  indicated  below. 

If  this  acquisition  process  is  modeled  after  a 
RASSP  Model  Year  situation  where  the  design 
system  has  provided  models  to  generic  software 
test  beds  in  the  specific  application  area  (or  a 
target  algorithm  development  test  bed  discussion 
later  in  this  section).  Then,  the  extended 
study/evaluation  phases  of  the  process  can  be 
reduced  to  a  few  months  of  evaluation.  The 
generation  of  “next  year’s”  Model  Year  would 
then  be  based  on  an  interoperable  upgrade  and 
could  be  quickly  assembled  from 
hardware/software  model  libraries  resident  within 
the  design  system.  After  conceptual  and 
architectural  verification,  assessment  tools  can 
be  used  to  quickly  provide  cost/performance 


Concent  to  Contract  Award 

Contract  Award  to  Production 

Month 

Activity 

Activity 

1 

Concept 

Contract  Award 

A. 

White  Paper 

J 

4 

5 

Evaluation/Funding  authorization 

Preliminary  Design  Review 

6 

7 

Study  Award 

Proof  of  Design 

8 

Trades/LCC/ROI/MTBF/Plan 

FAB  Prototype 

9 

Test 

10 

Report 

Software  Integration 

11 

12 

EvaluationA^ost/Schedule 

13 

Critical  Design  Review 

14 

Draft  Engineering  Change  Proposal 

15 

16 

Proof  on  Manufacture 

17 

Rework 

18 

Fact  Finding/Authorizations 

Procurement 

19 

Fabrication  (Prod.  Plant) 

20 

Test 

21 

Qualification 

22 

23 

Request  fw  Proposal/BAFO 

24 

Final  Engineering  Change  Proposal 

25 

Subsystem/System  Integration 

26 

27 

Evaluation/Selection 

System  TestAalidation 

28 

Ftvmal  Demonstration 

29 

30 

Contract  Award 

Production  Contract 

TABLE  3.11-1,  HISTORICAL  INSERTION  TIMELINE 
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statistics.  Logistics  test  beds  can  further  be 
exercised  to  provide  data  necessary  for  the  final 
contract  decision  based  on  a  complete  product 
data  model.  Thu  typical  separation  of  concept 
design  and  detail  development/manufacturing  is 
no  longer  necessary  since  both  can  be 


CONCl 

EPT  TO  PRODUCTION 

MONTH 

ACTIVITY 

1 

CONCEPT  DESIGN 

COMMENT  AWARD 

2 

REQUIREMENTS 
DEVELOPMENT 
FINALIZATION  CONTRACT 
BID 

3 

REQUIREMENTS 
VERmCATION  ON  HIGH 
LEVEL  MODELS 

4 

STRAWMAN’S  DESIGN 
ASSESSMENTS 

5 

DESIGN 

SELECnONA^RMCATION 
ON  TEST  BEDS 

6 

DETAIL  DESIGN 

7 

TRACEABLE 

REQUIREMENTS 

VERIHCATIONS 

8 

DEVELOPMENT  OF 

PRODUCT  DATA  MODEL 

9 

CRITICAL  COMPONENT 

BRASSBOARD 

DEMONSTRATION 

10 

FINAL  VERMCATION 

11 

FINAL  DOCUMENTATION  & 
REVIEW 

12 

PRODUCTION  RELEASE 

totally  overlapped.  The  manufacturing  process  is 
simulated  prior  to  making  a  build  decision. 
Manufacturing  resources  have  been  exercised 
through  demonstration  and  continuing  upgrades 
to  databases.  Their  facilities  have  been 
previously  qualified  for  RASSP  processor 
technology. 

An  example  of  this  integrated  effon  and  its  time 
line  is  indicated  below.  Obviously,  each 
candidate  system  has  its  unique  requirements, 
starting  point,  and  complexity  level  that  will 
significantly  effect  this  timeline.  Programmatic 
elements  of  budgets,  priorities  and  planning  will 
also  control  the  activity  flow.  However, 
conceptually  it  is  a  new  way  to  look  at  the 
acquisition  process  checks  and  balances  issues. 

Particularly  important  to  the  candidate  target 
systems  is  the  strawman  design  assessments  that 
assure  high  payoff  solutions  of  low  risk.  The 
power  of  the  strawman  approach  is  in  the 
comparisons  of  quantitative  data  developed  from 
the  conceptual  design  simulation  and  analysis. 
Weakness  in  candidate  approaches  focuses 
necessary  action.  Advantages  of  point  design 
over  “standard”  can  be  evaluated  in  terms  of  the 
overall  program  strategy.  Data  can  be  condensed 
through  parameter  comparison  charts  for 
weighting  of  factors  and  final  decision  by 
Program  Management.  The  scope  of  the  trade 
parameters  to  be  analyzed  can  be  uniquely 
defined  for  each  program.  Examples  of  trade 
parameters  are  listed  in  Table  3.1 1-3. 
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TRADE  PARAMETERS 


LCC 

TESTABILITY 

COVERAGE 

UNIT  COST 

MAINTAINABILITY 
AND  RELIABILITY 

NRE 

RISK 

ASSESSMENTS- 

COST/SCHEDULE 

MTBF 

PRODUOBILITY 

SIZEAVEIGHT 

CHANGE 

FLEXIBILITY 

PROGRAM  SIZE 

GROWTH 

POWER 

COMMONALITY 

MODULE/TYPES 

PERFORMANCE 

MARGINS 

^  CHIPS/TYPES 

SUPPORT 

SOFTWARE 

AVAILABILITY 

TABLE  3.11-3,  TRADE  PARAMETERS 


3.11.1  Candidate  Systems  And 
Classes 

Table  3.1 1-4  lists  Raytheon  systems  that  contain 
significant  signal  processing/processor 
technology.  Table  3.11-5  provides  a  brief 
description  of  key  programs  that  employ 
commercially  based  signal  processing  systems. 
The  majority  of  the  systems  have  had  signal 
processor  upgrades  within  the  last  five  years, 
indicating  a  continuing  pressure  for  increased 
performance.  Recent  programs,  where 
commercial  based  processors  have  been 
incorporated,  are  identified  and  individually 
discussed  in  later  paragraphs. 


99 


UNCLASSIFIED 


I 


SYSTEMNAME 

SERVICE/ AGENCY 

CONTRACT# 

STATUS 

Last 

Upgrade 

AREA 

GBR-T 

ARMY/SDG 

DASG60-87-C-0014 

Awarded 

1992 

RADAR 

TARTAR 

BLKLILm 

NAVY/NSSC 

N00024-85-C-5507 

N00024-87-C-5342 

N00024-87-C-5501 

Fielded 

■ 

ATR&ECM 

PAVE  PAWS  SITE  L 

n.  ra.rv 

AERPORCE/ESD 

F19628-76-C-0146 

F19628-76-C-0146 

F19628-84-C-0030 

F19628-84-C-0030 

Fielded 

1976 

1976 

1984 

1984 

EW&ECM 

liWiaMriiiilJIiM 

AIRFORCE/ ESD 

F19628-83-C-0113 

Fielded 

1983 

EW&ECM 

BMEWSm 

(FYL) 

AIRFORCE/ ESD 

F19628-88-C-0032 

Fielded 

1988 

EW&ECM 

CCSRADANE 

AIRFORCE/ ESD 

FI  9628-90-C-0070 

Fielded 

1990 

SIGINT&EW 

COBRAJUDY 

AIRFORCE/ ESD 

F19628-79-C-0023 

Fielded 

1979 

SIGINT&EW 

WAAS 

NAVY/S&NWSC 

N00039-78-C-0075 

Fielded 

1984 

EW 

ROTHR 

NAVY/S&  NWSC 

N00039-90-C-0027 

EDM 

1990 

COMM&SIGINT& 

ATR 

SWOTHR 

NAVY 

IDP  91D-236 

1991 

COMM&  SIGINT 

TDWR 

FAA 

DTFA01-89-C-00002 

1989 

ATR  &  COMM 

AEGIS 

NAVY/NSSC 

N00024-90-C*5114 

Fielded 

1990 

ATR&ECM 

ASOP 

AIR  FORCE /RADC 

F30602-84-C-0094 

Fielded 

1987 

SPACE*  EW&ECM 

SEA-SPARROW 

NAVY/NSSC 

N00024-89-C-5112 

Fielded 

1987 

AtR&  ECM 

RTWP 

ARMY/SDC 

DASG60-88-C-0064 

IN  PROGRESS 

1988 

SPACE 

MILSTAR 

AIRFORCE/ ESD 

F1628-85-C-0004 

EEMd 

1989 

SPACE  &  COMM 

NESP 

NAVY/S  4  NWSC 

N(K)039-82-C-0146 

EDM 

1990 

SPACE*  COMM 

CC»RADANE 

AIR  FORCE/ ESD 

F19628-90-C-0070 

1990 

SIGINT 

SPS-49 

NAVY/NSSC 

N00024-89-C-561  8 

In  Process 

Mmm 

ATR&ECM 

GPS 

USAF/ASD 

F08630-91-C-0053 

In  Process 

1991 

SPACE 

lATC 

FAA 

1DP91D-213 

In  Process 

1992 

ATR 

MMIC 

NAVY/NASC 

N00019-91-C-0210 

Fielded 

1991 

BCM&  SIGINT 

BSTS 

AIRFORCE /SSD 

F04701-87-C-0023 

Fielded 

1987 

SPACE 

RAMP 

CANADIAN  GOVT 

P005-2400  AF21  125 

Fielded 

1984 

ATC 

CART 

AIR  FORCE/ RADC 

F30602-88-C-0080 

IISSSHHMI 

1988 

ECM&  SIGINT 

D3  FIRE  CONTROL 

ARMY/AMMCCOM 

DAAA21  -88-C-0025 

Fielded 

1988 

EMGWS 

AAS 

FAA 

135076,  475475 

Fielded 

lEESHi 

wsjammmmm 

CX:S  MK2CDC 

NAVY/NSSC 

N00024-88-C-6067 

Fielded 

1989 

ATC  1 

TABLE  3.11 ‘4,  RAYTHEON’S  RELEVANT  SIGNAL  PROCESSING  PROGRAMS 
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MIDWAVE  LASER 
RADAR 

NAVY 

" 

Prototype 

■i 

ECM 

BANSHEE 

ARMY 

.. 

Prototype 

1989 

ECM 

AIRFORCE  &  NAVY 

-* 

Prototype 

1986 

ECM 

AIjQ-184 

OORRELMION 

PRCXJESSOR 

AIRFORCE 

Prototype 

1992 

ECM 

BRVAD 

BMO 

F04704-87-C-0116 

EDM 

1988 

PENAIDS 

MATES 

NAVY 

PROPOSAL 

1992 

ECM 

raCITALRECIEVER 

AIRFORCE/ NAVY 

— 

Prototype 

NEW 

SPACE/ COM/ EW 

SLO  32/54  ETU 

NAVY 

Prototype 

mam 

ESM 

MDOT 

NAVY 

F33615-90-C-1433 

AT»v1 

1992 

ECM 

Mine  Hunting  Sonar 
AN/AOS-20 

NAVY 

N00019-91-R-0021 

N00019-92-G-0072 

ADM/EDM 

1991 

Sonar  Detection  and 
classification 

Kingfisher 

Avoidance  for 
AN/SOS-26,  56 

"navy 

N00024-88-G-6051 

N00024-90-G-6079 

ADM/EDM 

1990 

Sonar  Detection  and 
classification 

ESraKwni 

NAVY 

N00024-89-C-6115 

ADM/EDM 

1990  - 

Sonar,-  Simulation 
and  Stimulation 

R^2nBJ3B3313||| 

Raytheon 

IR&D 

ADM/EDM 

1991 

Sonar  Detection  and 
classification 

1  Team  Trainer  for 

1 AN/BSY-2 

NAVY 

N00024-91-C-6505 

ADM/EDM 

1991 

Sonar,-  Simulation 
and  Stimulation 

NAVY 

N00019-89-R-0101 

Proposed 

1992 

Sonar  Detection  and 
classification 

Transient  Signal 
Processor 

Raytheon 

IR&D 

Fielded 

1990 

Sonar  Detection  and 
classification 

Trident  Sonar 
i^ocessor  JHU/APL 
analyzer  (TSPAN) 

NAVY 

N00039-87-C-5301 

Fielded 

njjjmiii 

Sonar;  Detection  and 
Classification 

Trident  Shore-Based 
Maintenance  Trainer 

NAVY 

N66604-86-C-0136 

Fielded 

1987 

Sonar;  Simulation 
and  Stimulation 

On-Board  Trainer  for 
AN/SOO-89 

NAVY 

N00024-85-C-6132 

N00039-89-R-0015 

Fielded 

1986 

Multipurpose 

Console  AN/BSY-1 

NAVY 

IBM  P.O  289664 

IBM  P.O.  270165 

Fielded 

1983 

Sonar;  Comm,  and 
Navigation 

NAVY 

N00024-82-C-6242 

N00024-89-C-6115 

Fielded 

1981 

Sonar,  Detection  and 
Communication 

ITglQSSSiilQSH 

ESSSuSSIHli 

AIRFORCE 

Internal  Development 

Demonstration/ 

Validation 

1991-2 

Air  to  Air  Missiles 

AMRAAM 

AIRFORCE 

CONTRACT 

Production 

1989 

Air  to  Air  Missiles 

VHSIC  Signal 
Processor 

MICOM 

Internal  Development 

Proof  of 

Principle 

1990 

Ground-based  radar. 
Missile 

Applications 

iiOCiHBHMi 

NAVY 

N00024-87-C-5321 

Production 

1989 

Surface  to  Air 

Missiles 

Patriot  Multi-mode 
Seeker 

ARMY 

CONTRACT 

Right  Program 

1987 

Missiles 

AAAM 

NAVY 

N00019-88-C-0152 

E«M/VAL 

1989 

Missiles 

B35S!II]lCSiina» 

NAVAIR 

CONTRACT 

Production 

Missiles 

Maverick 

AIRFORCE 

CONTRACT 

Fielded 

1987 

Air  to  Air  Missiles 

Patriot  Air  Defense 

CBjSQHHHBB 

CONTRACT 

Fielded 

1989 

ATR,  Radar 

ASARG 

- 

- 

1991 

ATR 
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Airport  Surveillance  Radar  (92D>213)  --  A  S-band  Architecture  and  Critical  Technologies  for  New 
ASR  system  using  off-the-shelf  components  for  the  signal  Generation  IFF  System  (92D-218)  A  brassboard 
processor.  Range  60nm  /  altitude  23,000  ft  with  dual  redundant  digital  signal  processor  to  implement  spread  spectrum 
channels.  Signal  and  data  processor  will  utilize  the  Low  waveform  processing  (Mark  X,  Mo^  4,  Mode  7,  Mode  8..  etc). 
Overhead  Array  Processor  (LOAP)  card  developed  by  Raytheon  Fabricate  and  demonstrate  this  monopulse  processor  using  a 
and  COTS  SBCs.  The  LOAP  boards  are  bas^  on  Motorola's  VHSIC  chip  set  in  0.9  micron  HMOS  technology. 

DSP96002  chips  with  a  VME  interface. 

f — - .  ■  .  '  .  . - . . - . 

Key  Components  for  Surface  Wave  OTH  Radar  Transient  signal  Processor  ••  This  IR&D  processor 
(92D-23d)  ••  The  technology  needed  to  build  a  ship  based  used  commercial  VME  6U  product  to  build  a  test  bed  for 
Prototype  HF  surface  wave  OTH  radar.  Hardware  includes  a  DEC  prototype  algorithm  development  that  also  had  the  flexibility 
4000  workstation  and  a  MASPAR  parallel  processor.  New  for  at-sea  trials.  We  continue  to  upgrade  this  system  with 
functions  to  be  added  this  year  include  digital  beamforming  and  newer  versions  of  the  signal  processor  board  products, 
data  and  signal  processing,  detection  and  tracking. 

Fault  Tolerant  Processors  for  Space  Applications  Miniature  GPS  Receiver  and  Inertial  Navigation 
(92D-343)  ••  Design,  develop  and  test,  fault  tolerant  System  (92D-345)  ••  The  six  channel  Global  Positioning 
j  general  purpose  scalar  and  vector  processing  architectures  and  System  (GPS)  signal  processor  can  acquire  and  nack  up  to  six 
implementation  technologies  to  meet  the  demands  of  space  satellites  on  CIA  code,  P-code,  or  Y-code.  The  data  processor  is 
based  processors.  Specify  and  develop  the  design  concepts  for  for  the  miniature  GPS  receiver  (MGR)  processor,  the  NAV 
applying  these  fault  tolerant  design  concepts  to  a  RU3000  and  processor  and  the  adaptable  interface  unit  The  TMS320C30  or 
RH  -32  chip  set  based  design.  The  signal  processing  and  data  TMS320C40  has  been  selected  for  this  processor.  Software  to 
reduction  (detection  processing)  function  requiring  730  M  bits  run  on  this  processor  chip  will  be  written  in  Ada  using  the 
of  memory  and  2JS  GOPS  of  32-bit  scalar  throughput.  Tartan  design  Ada  support  software  environment. 

Advanced  Automation  System/Sector  Suite,  Follow  on  Early  Warning  System  (FEWS)  Contract 
Contract  #135076  and  475475  —  Issued  by  IBM  for  #F040701-85-R*002  »  Issued  by  Grumman  Space 
FAA  Air  Traffic  Control.  Raytheon  developed  a  workstation  Systems  Division,  for  USAF.  applies  to  both  militarized 
common  console  which  includes  a  2048  x  2048  roster  display  commercial  and  custom  designed  architectures.  Signal 
controller  that  drives  a  Sony  20”  x  20”  color  monitor.  The  processing  is  performed  by  the  Detection  processor  and  with 
display  controller  used  a  commercial  digital  signal  processor,  the  Vector  processor.  Some  commercial  processing  resources 
an  AT&T  DSP32C.  The  DSP  provides  10  COPS  and  operates  as  used  on  BSTS  are  Scalar  processors  (17S0A  for  BSTS  and  32 
a  geometry  engine  for  the  display.  bit  RISC  for  FEWSO  and  PI-Bus  for  BSTS. 

Real  Time  Waveform  Processor  (RTWP)  Contract  MIDWAVE  LASER  RADAR  -  The  system  utilizes 
#DASG60-88-C*0064  —  The  RTWP  is  a  programmable  commercial  grade  AT&T's  DSP32C  and  DSP16A,  Array 
digital  signal  processor  that  can  be  integrated  into  an  SDI  Microsystem's  HDSP66111,  Plessy's  PSDP16330A,  and  IDTs 
radar.  The  major  result  of  the  program  is  producing  a  Stand  7381  processors  and  ALUs  for  implementing  a  real  time  digital 
Alone  Correlator  Assembly,  utilized  for  pulse  compression,  receiver.  This  processor  is  capable  of  computing  FFTs,  and 
that  is  capable  of  greater  than  4  terra-ops  in  performing  either  data  correlation,  extracting  the  range  and  Doppler 
correlations  or  FIR  filtering.  It  is  bas^  on  Residue  Number  information,  and  performing  signature  analysis.  It  operates  in 
System  (RNS)  custom  IC's  produced  by  Raytheon  that  are  a  2S0MHz  Doppler  bandwidth  for  IR  missile  detection, 
capable  of  operating  at  the  system  bed  of  62MHz. 

Processing  System  Designs  Using  Open  Patriot  Enhancements,  Digital  Signal  Processor 
Architecture  Interconnect  Standards  (92D-2S6)  —  IR&D  (92D-133)  --  A  major  re-engineering  effort  is  being 
Design,  integration,  test  and  demonstration  of  the  industry's  undertaken  to  design  a  replacement  digital  signal  processor  for 
first  Futurebus-t-  based  multiprocessor  system  and  integration  the  PATRIOT  system.  In  addition  to  supporting  all  existing 
of  a  commercial  off  the  shelf  operating  system  (UNIX  or  functional  modes  within  strict  time-lines.  Given  the  extended 
POSIX).  Ada  run-time  software  with  the  Futurebus-t-  system,  development  cycle  times  associated  with  bringing  a  new 
The  system  contains  high  performance  processors  (R3()()0,  subsystem  from  concept  to  a  fielded  production  unit,  it  is 
68040),  memory,  standard  110  channeb  (NTDS  Fast,  15530,  imperative  that  this  IDP  leverage  off  the  latest  commercial 
and  SAFENET  II),  SCSI  disk  interface  with  file  management  trends,  including  working  closely  with  leading  edge 
software,  a  Bus  monitor  interface,  and  a  VME  Bridge  interface,  microprocessor,  DSP,  memory,  and  semiconductor 
Raytheon  continues  to  play  a  major  role  in  the  technical  organizations,  to  ensure  that  a  product  developed  in  the  1992 
development  of  the  Futurebus-t-  standards  within  the  IEEE  to  1995  frame  provides  a  competitive  solution  for  production 
commiaee,  including  leadership  of  an  Expert  committee  at  the  in  the  year  2000. 

IEEE's  request  DoD  has  identified  the  commercial  IEEE  896 
Futurebus  as  a  basis  for  future  high  performance  systems. 

SAFENET  n  LAN  technology  based  upon  the  broadly  supported 
commercial  ANSI  X3T9.5  fiber  distributed  data  interface 

(FDDI)  is  also  being  supported  on  this  project.  _ 
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Next  GcDcratlon  Computer  Resources  (NGCR), 
Contract  «  N00039-90-C-0085  ••  For  U.S  NAVY! 
SPAWAR.  NCGR  is  an  ongoing  development  program  to| 
develop  open  computer  resource  standards  for  use  in  the  mid 
90's  and  beyond  (i.e.  Futurebus-r,  two  different  ISA's, 
SAFENET  LAN  interfaces,  etc..).  Raytheon  is  applying  the 
IEEE  Futurebus-t-  standard  a  VME  based  circuit  card  assembly 
and  bridge  coimections  to  the  Futurebus-t-  baclcplane.  Raytheon 
has  selected  the  military  VAX,  based  on  a  widely  used 
commercial  processor  engine,  to  demonstrate  the  evolution  of 
a  proprietary  architecture  commercial  product  to  the  evolving 
open  architecture  philosophy.  The  second  ISA  processor 
selected  was  the  MIPS  R3000 

SLQ-32/S4  Emitter  Tracking  Unit  (ETU)  -  The  ETU 
employs  multiple,  commercially  available  embedded 
processors  to  detect,  identify  and  track  emitters  across  the 
microwave  bands.  A  32-bit  digital  signal  processor 
(TMS320C30  DSP)  provides  detection  capability  for  emitters 
in  dense  signal  environments  of  up  to  three(3)  million  pulses 
per  second.  Redundant,  distributed  32-bit  CISC  processors 
(M68040)  provided  identifleation  and  tracking  of  more  than 
500  emitters  for  both  ESM  and  ECM  systems.  An  industry 
standard  VME  bus  interconnects  all  processing  functions  to 
allow  insertion  of  future  enhancements  hardware  and  Ada 
provides  easy  transportability  of  applications  software. 

Next  Generation  Air  Traffic  Control  system  (92D- 
206)  "  This  is  an  air  traffic  control  system  which  will 
process  and  display  position  information  in  the  form  of 
digitized  raw  radar  data,  digitized  extracted  data  and  global 
positioning  system  (GPS)  reports.  Incorporates  state  of  the  art 
low  cost  commercial  computers  and  software  hosted  on  a  UNIX 
SV  R4  operating  system  employs  the  Motorola  Delta  system. 

CCS  Mk  2,  Common  Display  Console  CDC), 
Contract  #  N00024-88-C-6067  »  For  the  Naval 
Systems  Command.  Each  CDC  graphics  function  includes  two 
circuit  cards;  a  graphics  processor  and  a  graphics  generator 
interconnected  on  a  VME-bus  features  the  Silicon  Graphics 
custom  ASIC  chip  (Geometry  Engine)  providing  20  MFLOPS 
capacity  and  a  Weitek  3132  floating-point  processor 

DIGITAL  RECEIVER  —  A  broad  band  digital  receiver  is 
being  developed  using  commercial  grade  A/D  converters, 
memory  and  DSP  chips  for  demonstrating  over  1-GHz  of 
bandwidth  with  60dB  of  dynamic  range  for  applications  in 
radar  and  ESM.  Industrial  parmers  such  as  TRW  and  Honeywell 
are  supporting  this  effort. 

Kingfisher  Avoidance  for  AN/SQS-26,  56  —  Uses 
commercial  VME  6U  DSP  (i860)  boards  for  signal  processors. 
We  combine  these  with  the  Navy's  processor  suite  to  provide  a 
solution  that  ties  into  the  existing  AN/SQS-S6  systems,  using 
their  sonar  for  data  acquisition  and  augmenting  their 
performance  with  the  new  object  avoidance  capability. 

Team  Trainer  for  AN/BSY-2  -  The  trainer  for  the 
AN/BSY-2  simulates  and  stimulates  real  operational  hardware' 
at  a  shore-based  training  site.  We  have  used  commercial 
technology  to  attain  20  GFLOPS  of  high  performance  signal 
processing.  The  equipment  also  emulates  the  functions  of  a 
military  s  andard  signal  processor,  the  EMSP,  in  the  AN/BSY- 
2  system. 

Shore-Based  Trainer  for  AN/SQQ-32  -  This  contract 
used  the  commercial)  technology  from  the  AN/BSY-2  Team 
Trainer  for  a  shore-based  trainer  for  the  AN/S(3Q-32  mine 
hunting  system  now  in  production.  VME  6U  and  9U  signal 
processor  products  were  used.  The  portability  of  software  and 
the  tendency  of  the  commercial  world  to  preserve”  upward 
compatibility  in  the  product  line  made  this  possible. 

International  Sonar  System  (ISS)  IR&D  ••  This 
internal  development  was  formulated  to  provide  the  basis  for  a 
building-block  approach  for  common  use  in  a  number  of  US 
and  international  systems.  To  meet  full  military  performance 
requirements,  we  selected  VME  format  6U  boards  with 
conduction  cooling,  largely  because  of  the  availability  from 
multiple  sources  of  commercial  product  in  this  format.  We 
have  developed  a  sigiul  processor  board  (i860-based),  a  board 
for  fiber  optics  interface  for  high  speed  data  I/O,  and  an 
approach  to  a  dual  synchronous  bus  for  the  backplane  routing 
of  high  speed  data.  We  are  exploring  cross  licensing 
agreements  with  the  commercial  vendors  for  their  product. 

Mine  Hunting  Sonar  for  AN/AQS>20  —  Raytheon 
recently  won  this  highly  competitive  procurement  contract  for 
a  helicopter-towed  sonar  for  mine  hunting,  comprised  of 
signal  processing  electronics  both  in  the  towed  body  and  the 
helicopter.  We  use  the  signal  processing  building  blocks  from 
Raytheon's  IR&D  development  together  with  commercially 
purchased  VME  6U  products  for  the  CPU,  memory,  and  I/O. 
The  success  of  our  approach  demonstrates  that  NDI  and  COTS 
solutions  are  cost  effective  for  full  military  environments.  For 
the  shore-based  portion,  we  used  the  equivalent  equipment  in 
their  commercid  form,  preserving  full  compatibility  with 
additional  cost  savings. 

ALQ-184  CORRELATION  PROCESSOR  ••  A  new 
processor  was  developed  for  pulse  repetition  interval  analysis 
of  multiple  emitters  with  patterned  or  steady  pulse  repetition 
intervals.  Commercial  grade  Texas-Instiuments  TMS320  DSP 
chips  were  used  to  implement  and  flight-test  the  processor. 

BANSHEE  ••  Commercial  dual  FFT  pnocessors  were  used  in  a 
flight  test  and  radar  range  tests.  The  overall  digital  receiver  is 
capable  of  real  time  computing  pulse  repetition  frequency, 
angle  of  arrival  and  frequency  of  the  emitter  for  high 
sensitivity  radar  altimeter  detection. 

TABLE  3.11-5  CONTINUED,  COMMERCIAL-BASED  SIGNAL  PROCESSOR 

PROGRAMS 

Many  of  these  candidate  systems  are  good  system.  Screening  of  diese  systems  has  resulted 

demonstration  vehicles  for  the  RASSP  program  ®  reduced  but  still  large  set  of  leading 

and  offer  opportunities  for  image  performance  candidates.  Here  they  are  organized  by  business 
and  cost  improvements  within  the  weapon  area  within  Raytheon’s  government  group. 
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•  Equipment  Division 

•  GBR  Ground  Based  Radar  -  Army 

•  AN/SPS-49  Long  Range  Surveillance 
Radar  -  Navy 

•  Submarine  Signal  Division 

•  CCS  MK-2  Submarine  Combat  Control 
System  -  Navy 

•  AN/SQS-32  Mine  Hunting  Sonar  -  Navy 

•  AN/AQS-20  Mine  Hunting  Sonar  -  Navy 

•  Electromagnetic  Systems  Division 

•  AN/ALQ- 1 84  Electronic 
Countermeasures  -  AF 

•  AN/SLQ-32/SLQ-54  Electronic 
Countermeasures  -  Navy 

•  Missile  Systems  Division 

•  Missiles  —  Army,  Navy,  Air  Force 

•  Patriot "  Air  Defense  System  -  Army 

•  CORPSAM  -  Air  Defense  System  - 
Army 

•  EMR  "  Electronic  Combat  Multifunction 
Radar- AF 

•  ASAP  -  Airborne  Shared  Aperture 
Program  -  Navy 

3.11.2  Missile  Systems  Candidates 

The  missile  systems  are  particularly  interesting 


candidates.  They  are  in  the  process  of  upgrades 
and  the  growth  of  signal  processing  has  been 
explosive.  Characteristics  of  the  missile  seeker 
processor  technology  are  itemized  here: 

•  Desired  Processing  Capability  Typically 
exceeds  Volume  Constraint 

•  Throughput  Has  Grown  From  0.5  MOPS 
(Sparrow  7M)  to  3000  MOPS  (ASARG) 

•  Continued  Growth: 

•  Processors 

•  Absorbing  Former  Analog  Functions 

•  Scale  With  Technology 

•  Scale  With  Missile  volume 

•  Support  Maturing  of  Algorithms 

•  Interoperable  with  Missile  Sensor  and 
Guidance  Subsystems 


The  expansiveness  of  the  missile  seeker 
processing  functions  places  demands  on 
algorithms,  architecture  and  Software.  A  typical 
set  of  algorithms/functions  partitioned  by 
processor  architecture  demonstrates  the 
complexity  level  of  the  issues  to  be  resolved  by  a 
RASSP  design  system  providing  Model  Year 
processors. 


THREATS ' 

SMART  ECM 

PHASED  ARP 

ADAPTIVE 

NTCR/ATR 

STARING  AY 

IMAGING 

STEALTH 

DUALIR/i 

FUSION 

IR/EO/MMW 

KNOWLEDGE  BASED 

TABLE  3.11-6,  GROWTH  OF  PRODUCT  FUNCTIONALITY 


104 


UNCLASSIFIED 


_ 33 

GIB 


DECIMATING  FILTE 


APnVE 
BEAMFORMING 


ADAPTIVE 

EQUALIZATION 


ADAPTIVE  NULLING 
WEIGHT  GENERATION 


WAVEFORM  DECODIN 


ADAPTIVE  DATA 
EXTRAPOLATION 


DOPPLER  FILTERDM 


AD  APnVE  CLUTTER 
REACTION 


MAGNITUDE 

DETECTION 


T  DETECTION 
INTEGRATION 


PARALLEL  SIMD/MIMD 


RISC  MULTIPROCESSOR 


mmsmm 


ALARM  RATE 


RTBsIMBarigMi 


TAR 

IDENTIHCATION/CLASS 

DFICATION 


DATA 


TARGET  TRACK 


AUTOP 

CONTROL 


UIDAN 


TABLE  3.11’7,  MISSILE  PROCESSING  ALGORITHMS 


The  current  generation  of  processors  in  this  area 
relies  heavily  on  commercial  based  technology  in 
the  DSP  and  microprocessor  area.  Typical 
devices,  architecture  and  interconnect  structures 
are  identified  below. 
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ELEMENT  (PE) 


TYPICAL  PE 


PE 

INTERCONNECT 


INPUT/OUTPUT 


DIRECT  MINIMAL 
BUFFERING 


ROW  AND 
COLUMN  FRAME 
BUFFER 


RISC 


FIFO  BUFFERED 
BUSSES 

MULTIPROCESSOR 

-TELEMETRY 

-VO 

-CONTROL 


3.11-8,  MISSILE  PROCESSING  ARCHITECTURE 


Leading  candidates  within  this  category  are 
systems  demanding  advanced  technology  and  the 
ability  to  stay  state-of-the-art  in  a  cost  effective 
fashion.  These  systems  arc: 

Millimeter  Wave: 

•  Autonomous  Synthetic  Aperture  Radar 
Guidance  (ASARG)  -  AF 

•  Joint  Direct  Attack  Munitions  (JDAM)  - 
AF/Navy 

•  Advanced  Kinetic  Energy  Missile  (ADKEM) 
-Army 


Infrared  Imaging: 

•  Sidewind  AIM-9X  -  AF 

RF/IR  Dual  Mode 

•  Advanced  Sparrow 

•  Standard  Missile  (SM-2)  Block  BIB  -  Navy 

Each  of  these  systems  also  has  significant  ATR 
functions  and  is  currently  have  test  beds  in  the 
form  of  capture  flight  configurations,  hardware- 
in-the-loop  (HIL)  facilities,  laboratory  evaluation 
test  beds  and/or  software  simulation/analysis  test 
beds.  The  ATR  functions  are  at  various  levels  of 
complexity  as  itemized  below. 
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— ■rAkGETSVSim — 

1 

AUTOMATIC  TARGET  RECOGNITION  (A  I  K) 
FUNCTION 

ASARG  JDAM 
TOMAHAWK 

AIR-TO-GROUND  SYNTHETIC  APERTURE  IMAGING 
OF  FIXED,  RE  LOCATABLE,  NAVIGATION  POINTS 

AIM-9X 

AIR  TO  GROUND  LOW  CONTRAST  SMALL  TARGET 
DETECnON,  IMAGING  AND  TERMINAL  AIM  POINT 
SELECTION 

ADVANCED  SPARROW 

SEA-SKIMMER  AND  CRUISE  MISSILE  MULTI 
SPECTRAL  DATA  FUSION  AND  CENTROID 
TRACKING 

ADKEM 

ANTI-TANK,  ANTI-AIR  HIT  TO  KILL  RECOGNITION 
AND  AIMPOINT  SELECTION 

SM-2  IBB 

DATA  FUSION  AND  CENTROID  TRACKING 

3.11-9,  MISSILE  ATR  FUNCTIONS 


3.11.3  ATR  Category 

In  many  ways,  the  RASSP  effort  during  1993- 
1997  can  provide  maximum  benefits  to 
concurrent  development  effons  in  related 
processing/processor  initiatives.  In  the 
automatic  target  recognition  “class  of  problem," 
there  are  several  programs  which  result  in  test 
beds  for  evaluation  of  future  system  technology. 
Future  ATR  processing  technology  includes  high 
resolution  signal  conditioning  for 
STARING/SCANNING  IR  arrays,  FLIRS,  EO 
Sensors,  and  wide  band  width  RF  waveforms. 
In  some  cases,  data  fusion  techniques  are 
applied  and  further  augmented  with  acoustic 
sensors  and  links  to  queuing  systems.  Neural 
networks,  wavelet  transforms,  model  based 
vision  advanced  techniques  are  included  in  the 
broad  and  growing  set  of  algorithms  originally 
dominated  by  direct  correlation  and  statistical 
pattern  recognition. 

Some  of  the  concurrent  developmental  efforts 
underway  with  their  related  programs  arc  listed 
below. 

•  Advanced  Land  Combat  Vehicle 
Technology  (ALCVT)  -  DARPA 
Multi-sensor  Feature  Level  Fusion 
(MSFF) 

BIT/DARPA/ARDEC  D-3  Fire  Control 
Program 


•  SCVision  Research  -  DARPA 

Smart  Weapons  Test  Bed  NGS 

•  Air  Target  Algorithm  Development 
Test  Bed  -  AF 

Advanced  Digital  Radar  Imagery 
Exploitation  (ADRIES) 

Sensor  Algorithm  Research  Export 
System  (SARES) 

Multi  attribute  ID  Analysis  (MAIDA) 

Intra  Radar  Aircraft  Signature  Fusion 
Air  to  Air  Covert  Sensor  Technology 
Ultra  High  Range  Resolution  (ARTI) 

•  Multi-Sensor  Aided  Targeting-Air 
(MSAT)  -  Army 

Advanced  Air  Defense  Elector-Optics 
System 

These  programs  are  representatives  of  a  widely 
supported  methodology  in  the  evaluation  of  ATR 
systems/sensors  and  processors.  Generally, 
these  evaluation  systems  start  as  pure  software 
emulators  where  models,  libraries,  algorithms, 
and  assessment  tools  are  brought  together  on 
high  performance  workstations  employing 
parallel  processing  techniques.  A  massively 
parallel  processing  computer  can  be  incorporated 
when  data  base/test  vector  sets  grow  large. 
Sensors  and  emulation  hardware  and  then  added 
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and  eventually  test  bed  platforms  suitable  for 
filed  operation  are  developed.  The  RASSP 
design  system  can  provide  both  software  models 
of  candidate  processors  and  later  rapid  turn 
around  demonstration  hardware.  The  use  of  high 
performance  workstations  and  massively  parallel 
processors  in  these  developments  provide  a 


sound  basis  for  transitioning  to  Model  Year 
signal  processors. 

The  conceptual  partitioning  of  the  software  test 
bed  for  the  Air  Target  Algorithm  Development 
system  is  presented  below  RASSP  processor 
models  can  be  built  for  all  or  pan  of  the  system. 


Figure  3.11-10,  Air  Target  Algorithm  Development  Test  Bed 
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Figure  3.11-11,  ALCTV  Phase  11  Block  Diagram 


An  example  of  a  hardware  test  bed  is  a  ALCVT 
Phase  n  possibility.  Here  the  processor  elements 
can  be  replaced  with  software  models,  emulator, 
or  demonstration  hardware  derived  from  the 
RASSP  system. 

3.11.4  Classes  Of  Systems  Which 
Benefit  Most  From  The  Model  Year 
Approach 

Model  Year  Processors  can  provide  substantial 
return  on  investment  for  those  imponant  DOD 
programs  where  threat  escalation  is  pushing 
advanced  hardware/software/algorithm 
technology  to  new  thresholds.  These  programs 
sponsor  advanced  activities  in  both  development 
and  research.  They  are  developing  evaluation 
test  beds  of  various  forms  and  are  looking  to 
advanced  signals  processing  for  solutions. 
Programs  mentioned  above  in  the  ATR 
discussion  are  good  examples.  Within  this 
context  there  are  several  other  criteria  that 


augment  the  realization  of  benefits.  These  criteria 
are  identified  as  follows: 

CRITERIA  A 

Dual-Use  Technology  might  be  related  to  such 
components  as  submicron  FIR  filters  for  HDTV 
and  radar,  or  modules  for  FUTURE  BUS,  or 
unique  High  Performance  Computer  kernels  and 
so  on. 

CRITERIA  B 

Continuing  Upgrades  occur  in  systems  where  the 
computational  requirements  of  algorithms  are 
currently  unbounded  such  as  imaging,  ATR,  and 
NCTR.  Also  in  this  category  are  systems  where 
processing  capability  must  keep  up  with  sensor 
technology  -  IR  STARING/SCANNING 
arrays,  LASER  RADARS,  wide  band  phased 
arrays,  multi-sensor,  towed  arrays.  Other 
systems  may  not  have  been  able  to  attain  the 
throughput/performance  requirements  due  to 
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size,  weight,  volume  or  cost  limits  and  must 
approach  their  goals  through  successive 
technology  upgrades. 

CRITERIA  C 

This  addresses  the  important  issue  of 
commonality.  Many  target  systems  would 
achieve  a  break  through  with  higher  sampling 
rates,  greater  dynamic  range,  adaptive  algorithm 
implementations,  etc.  If  these  performance 
benefits  can  be  realized  in  processors  that  are 
compatible  with  a  class  of  systems  that  includes 
both  the  commercial  and  DoD,  then  we  have 
identified  a  significant  RASSP  Target 

CRITERIA  D 

Allows  the  inclusion  of  target  systems  that  have 
commercial  twins.  Functional  differences  can 
exist  and  environmental  or  security  requirements 
may  differ  but  there  exists  a  need  in  both  areas 
for  improvements. 

Other  Categories  Of  Target  Systems 

In  addition  to  these  classes  of  developmental 
programs,  there  are  other  categories  that  can 
realize  benefits  from  the  Model  Year  approach. 

The  Rapid  Response  Model  can  be  extended  to 
include  upgrades  associated  with: 

•  Altercation  driven  very  rapid  response 

•  Potential  new  high  priority  threat 

•  Pre-planned  product  improvement  (P^D 

•  Obsolete  parts  (perhaps  unplanned) 

The  first  item  includes  activities  as  experienced 
during  Desert  Storm  where  response  time 


for  system  upgrades  was  accomplished  in  a  few 
months.  In  addition,  to  the  rapid  response  model 
with  tools  and  manufacturing  in  place,  the  ability 
to  have  resident  within  the  design  system  the 
model  of  the  next  generation  upgrade  would  be  a 
powerful  supporting  tool  in  the  decision  and 
implementation  process. 

Item  two  addresses  a  condition  where  a  new 
threat  has  been  identified  and  solutions  must  be 
evaluated  quickly.  When  the  solution  is  total 
validated,  the  ability  to  implement  an 
interoperable  insertion  in  short  order  can  be  very 
significant  to  our  defense  posture. 

The  preplanned  product  improvement  process 
must  determine  the  optimum  timing  of  the 
upgrade  to  obtain  the  best  cost/performance 
improvement  ratio.  Many  of  the  systems  are 
complex  and  require  mature  re-engineering  tools 
embedded  in  a  design  system  in  order  to  support 
a  low  risk  undertaking.  High  levels  of 
interoperability  with  last  generation  system  must 
be  support. 

The  obsolete  pans  or  diminishing  sources 
problem  afford  another  class  of  problems  that  can 
realize  benefits  from  the  Model  Year  approach. 
The  RASSP  design  system  provides  the  tools 
necessary  to  assess  various  approaches  such  as 
direct  functional  replacement  or  Model  Year 
insertion. 

3.11.5  Primary  RASSP  Insertion 
Targets 

Three  systems  were  established  as  primary 
targets  for  RASSP  Insertion  at  each  division. 

The  material  in  this  section  was  presented  at  the 
Final  Program  Review. 
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3.11.5.1  Equipment  Division  Candidates 


Principle  Benchmarks 
4x  performance  increase  for 
volume  search 


System  Candidates 
Long  Range  Surveillance  Radar 
AN/SPS-49 


MILSTAR  Tactical  Comm 


pround  Based  Radar  (GBR) 


Planning  Considerations 
Production  Start  4(^93 
RASSP  model  in  1994 
RASSP  demo  in  1995 

FSED  System  4(392-4(394 
RASSP  model  in  1994 
RASSP  demo  in  1995 


FSED  System  4(392-4Q97 
RASSP  model  in  1994 
RASSP  demo  in  1995 


<2x  performance  increase  for 
sidelobe  cancel  algorithms 
>  4x  reduction  in  volume 
Commensurate  increase  in 
reliability 

Reduced  NRE  for  limited 
production  variants 
Reduced  cost  with  higher 
throughput  margins 


TABLE  3.11.12,  ED'S  PRIMARY  RASSP  INSERTION  TARGETS 


Target  RAASP  System:  AN/SPS-49  (V) 

MPU  ATD 

Contacts: 

Mr.  Robert  Pike  Mr.  Michael  Sosin 

NAVSEA  62X  Raytheon  Company 

430  Boston  Post  Road 
WaylancLMA  01778 
(508)  440-1599 

AN/SPS-49  (V)  System  Description 

•  2-D  Long  Range  Surveillance  Radar  for 
Fleet 

•  Pipelined  Signal  Processor,  Hardwired 

•  Digital  Sidelobe  Clanceller  in  Receiver 
Subsystem 

•  Waveform  Agile  with  Digital  Pulse 
Compression 

•  Requirements  Definition  for  Volume 
Search  (2-1/2-D)  Upgrade  in  Process 

Desirability  for  RAASP  Use 

•  Program  in  Production  for  16  years  with 
Major  Upgrades  every  7-8  years,  Lesser 
Upgrades  more  often 

•  Hi^  Throughput  is  desired  in  Digital 
Sidelobe  canceller  to  support  more 
sophisticated  Algorithms 


•  Higher  throughput  Required  in  Signal 
Processor  to  Support  Volume  Search 
Operation 

•  Programmability  required  in  signal 
processor  to  adapt  to  changing  threats 
between  major  upgrades 

Key  Functions  for  Upgrade 

•  Digital  Sidelobe  Canceller 

•  Reduce  quantity  of  existing  H/W 

•  Increase  available  H/W 
throughput 

•  Signal  Data  Processor 

•  Replace  hardwired  logic  with 
programmable 

•  Increase  throughput  to  support 
volume  search  operation 

Projections  for  RAASP  Utilization 

•  Perceived  added  risk  to  successful 
ongoing  program 

•  Run  as  parallel  effort  with  minimal 
interference 

•  Significant  MIL-SPEC  requirements 
levied  on  program,  inconsistent  with  use 
of  COTS  equipment. 
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Target  RASSP  System:  MILSTAR 
Tactical  Communication 

Contacts; 

Mr.  Joseph  Mardo 
Depanment  of  Air  Force 
HdqtrESD  (MILSTAR) 

Hanscom  AFB,  MA  01731 
(617)271-6051 

Mr.  Richard  Cfease 
Raytheon  Company 
1001  Boston  Post  Road 
Marlboro,  MA  01752 
(508)  490-1306 

Mr.  Robert  McGlothlin 

USN  Space  &  Naval  Warfare  Systems 

Command  PMW-156 

Washington,  DC  20363 

(703)  602-7107 

MILSTAR  Tactical  Communication 
System  Description 

•  Secure  EHF  Satellite  Communication 
System 

•  Tactical  versions  of  original  strategic 
system 

•  Anti  Jam  Techniques  with 
TRANSEaCOMSEC 

•  Multiple  modulation  techniques 

•  Multiple  communication  services,  low 
rate  to  high  rate 

•  Moderate  processing  load,  multiple  comm 
services 

Desirability  for  RAASP  use 

•  Multiple  programs,  i.e.  high  volume 
production 

•  Emphasis  is  on  cost,  volume,  and 
flexibility 

•  Programmability  required  for  upgrades 

Key  Functions  for  Upgrade 

•  Demodulator  —  multiple  techniques  must 
be  supponed 


•  TRANSEaCOMSEC -embedded 
TRANSEaCOMSEC  desired 

•  Baseband  Interface  -  multiple  channels, 
network  control 

Projections  for  RAASP  Utilization 

•  Identify  insertion  task  in  year  2 

•  Design/Fab/Test  insertion  task  in  year  3 

•  Test/Demonstrate  at  Raytheon  MILSTAR 
test  facility 

Perceived  Deterrents  To  RAASP  Use 

•  Perceived  added  risk  to  successful 
ongoing  program 

•  Run  as  parallel  effort  with  minimal 
interference 

Target  RASSP  System:  Ground-Based 

Radar 

Contacts:  Col.  William  Ryan 
USASDC 

Mr.  Leroy  Dirks 
Raytheon  Company 
Huntsville,  Alabama 
Boston  Post  Road 
(205)  955-4370 
Wayland,  MA  01778 
(508)  440-6823 

Ground  Based  Radar  System  Description 

•  Land  Based  X-band  phased  anay  radar 

•  Wide  bandwidth  high  resolution 
wavefoiras 

•  Real  time  target  classification  and 
discrimination 

•  Multiple  variants  for  Theater  Missile 
Defense  and  National  Missile  Defense 

•  High  processing  performance  required 

•  Contract  was  awarded  to  Raytheon 

Desirability  for  RASSP  use 

•  Program  about  to  start  full-scale 
development 

•  Higher  throughput  required  for  Solid 
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State  Amy  with  fiiUy  adaptive  nulling  Projections  for  RASSP  Utilization 

•  Identify  insertion  task  in  year  1993 

Key  Functions  for  Upgrade  •  Design/Fab/Test  in  year  1994 

•  Signal  Processor  •  Demonstrate  in  year  1995 

•  Reduce  quantity  of  existing  H/W 

•  Digital  Waveform  Generator  Perceived  Deterrents  to  RASSP  use 

•  Increased  processing  requires  •  Perceived  added  risk  to  NDI  approach 

distributed  Receiver/Exciter  architecture 


System  Candidates 

Planning  Considerations 

Principle  Benchmarks 

SONAR  MINE 

DETECTION  SET 

AN/AQS-20 

•  JULY  1992  -  MAY  1996 

•  RASSP  MODEL  IN  1994 

•  RASSP  DEMO  IN  1995 

•  IMPACT  FIRST 
PRODUCTION 

•  REDUCED  COST  WITH 
HIGHER  PERFORMANCE 
MARGINS 

•  VOLUME  AND  POWER 

FOR  HELICOPTER  AND 
TOWED  ARRAY 

•  IMAGING  AND 

DETECnON 

ALGORITHMS 

SUBMARINE  COMMAND 

AND  CONTROL  SYSTEM 
MARK  2  CCS  MK2 

•  OCTOBER  1988- 
OCTOBER  1993 

•  RASSP  MODEL  IN  1993 

•  RASSP  DEMO  IN  1994/5 

•  PRODUCTION  BREAK-IN 
IN  1995/96 

•  lOX  IMPROVEMENT  IN 
PROCESSOR 

CAPABILmES 

•  CONSOLIDATION  OF 
SPECIAL  PURPOSE 
ASSOCIATIVE 

PROCESSOR  INTO 
WORKSTATION 

•  SIGNIHCANT  INCREASE 
IN  LEVEL  OF 
AUTOMATION 

PASSIVE  TORPEDO 
DETECTTON/CLASSin- 
CATTON  LOCAUZATTON 
SYSTEM  (DCLASP) 

•  DECEMBER  1992- 
DECEMBER  1993 

•  RASSP  MODEL  IN  1993/4 

•  RASSP  DEMO  IN  1994/5 

•  MULTT-TARGET  DATA 
ASSOCIATION  &  TRACK 

•  COUNTERMEASURE 
INTERFERENCE 
REJECTION 

•  TORPEDO  LOCALIZATION 
BY  MULTI-PATH 

•  COMPENSATION  FOR 
PROPAGATION 
ENVIRONMENT 

TABLE  3.1 1-13,  SSD'S  PRIMARY  RASSP  INSERTION  TARGETS 
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3.11.5.2  Submarine  Signal  Division 
Candidates 

TARGET  RASSP  SYSTEM:  AN/AQS-20 
(XN-1)  SONAR  MINE  DETECTION 

Contacts: 

Mr.  Ken  Haas 
PEO(A)PMA210 
Dqjartment  of  Navy  Air  ASW 
Washington,  DC  20361-1210 
(703)  692-7697 

Mr.  Joe  Kuzneski 
Raytheon  Company 
1847  W.  Main  Road 
Portsmouth,  RI  02871 
(401)  847-8000 

AN/AQS*20  System  Description 

•  Helicopter  towed  mine  detection 

•  FSED  award  to  Raytheon  on  3  July  1992 

•  46  Month  Program;  2  equipment  sets 

•  Processing  in  towed  body,  helicopter, 
and  van 

•  Extensive  use  on  VME-format  modules 

Desirability  for  RASSP  Use 

•  Program  is  just  entering  full-scale 
development 

•  Processing  already  reliant  on  NDI  and 
COTS 

•  Has  modularity  suited  for  incremental 
upgrades 


DETILED  CHARACTERISTICS  OF 
AN/AQS.20  TARGET  RASSP  SYSTEM 
Key  Functions  for  Upgrade 

•  Beamforming  (spatial  processing)  in  the 
towed  body 

•  Detection  processing  in  the  helicopter 

•  Image  enhancement  in  the  helicopter 

•  Post-mission  data  analysis  in  the  van 

Projections  for  RASSP  Utilization 

•  Identify  insertion  area  in  year  2 

•  Test  developed  insertion  in  year  3 

•  Realize  cost  savings  in  first  production 

Perceived  deterrents  to  RASSP  use 

•  EDM  focus  on  successful  evaluation 

•  Resolve  with  integral  plans  and  non- 
disruptive  test 

•  Insertion  proves  more  difficult 

•  Resolve  with  encapsulation  and 
planned  accommodation 

•  Pay-offs  may  be  minimal 

•  Resolve  by  exploiting  performance 
enhancements 
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3.11.5.3  Electromagnetic  Systems  Division  Candidates 


System  Candidates 

Planning  Considerations 

Principle  Benchmarks 

HIGH  POWER 

COUNTER  MEASURES 
(HPCM) 

•  MARCH  1994  -  DECEMBER 
1998 

•  RASSP  MODEL  1994/5 

•  RASSP  DEMO  1995/6 

•  SYSTEM  PRODUCTION 

2000 

•  COST,  VOLUME,  POWER 

•  NUMBER  OF 
SIMULTANEOUS  THREAT 

TT?  APtf  ^ 

•  DYNAMIC  RANGE, 
SENSITIVITY 

•  RECONHGURATION 
CAPABILITY 

LOW  COST  EW  RECEIVER 

•  JANUARY  1 994  -  JANUARY 
1997 

•  RASSP  MODEL  1994/5 

•  RASSP  DEMO  1995/6 

•  SYSTEM  PRODUCTION 

1997 

•  COST,  VOLUME,  POWER 

•  NEW  THREAT 
RESPONSIVENESS 

•  EMITTER  SORTING 

DIGITAL  RECEIVER 

•  JANUARY  1993  - 
DECEMBER  1995 
PROTOTYPE 

•  RASSP  MODEL  1994 

•  RASSP  DEM  1994/5 

•  SYSTEM  PRODUCTION 

1997 

•  LEVEL  OF  THREAT 
ENVIRONMENT  DENSITY 

•  SENSITIVITY 

•  SINGULAR  VALUE 
DECOMPOSITION 

TABLE  3.11-14,  ESD*S  PRIMARY  RASSP  INSERTION  TARGETS 


TARGET  RASSP  SYSTEM  -  HPCM 

HPCM  is  an  acronym  for  High  Power  Counter 
Measures.  HPCM  is  a  standoff  jammer  mounted 
in  an  aircraft  like  a  Boeing  707.  The  aircraft  flies 
a  racetrack  path  over  friendly  territory  while 
sending  high  power  jamming  beams  into  enemy 
territory.  The  purpose  of  generating  the  jamming 
beams  is  to  blind  all  enemy  radar  to  the  location 
of  penetrating  aircraft.  Correctly  applied,  the 
jamming  provides  a  safe  corridor  through  which 
the  friendly  attacking  aircraft  can  penetrate  enemy 
defenses. 

PRIMARY  POINT  OF  CONTACT 
US  Air  Force  Wright  Laboratories 
Wright  Patterson  AFB,  OH 
ASD/WLAAWD-8 

PROGRAM  MANAGER 
Mr.  David  Misek 


PRIME  CONTRACTOR 
Raytheon  ESD 

CONTRACTOR  SYSTEM  ENGINEER 
Mr.  Lance  McBride 

HPCM  System  Characteristics 

The  HPCM  receiver  has  a  number  of  difficult 
signal  processing  tasks  that  can  be  optimized 
through  the  use  of  RASSP.  The  receiver  must 
handle  high  power  emitters  located  at  the  FEBA, 
as  well  as,  the  lowest  power  emitters  at  the  full 
penetration  range  of  the  strike  aircraft. 
Therefore,  the  receiver  must  have  sensitivity  in 
excess  of  —  100  dBmi  and  a  dynamic  range  in 
excess  of  80  dB.  The  receiver  looks  at  the  entire 
battle  environment  at  a  very  high  altitude  and 
therefore  sees  all  emissions,  both  enemy  and 
friendly.  Consequently,  the  radar  pulse  count 
that  the  receiver/processor  must  handle  is  very 
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high  in  excess  of  three  million  pulses  per  second 
in  any  one  GHz  band.  From  this  signal  density 
at  least  60  simultaneous  threat  tracks  must  be 
maintained  as  recipients  of  the  jamming  signal. 
Further,  in  the  presence  of  this  jamming,  new 
signals  must  be  identified  and  added  to  the  track 
file  within  a  period  of  two  seconds  after  they 
appear.  Angle  of  arrival  is  used  as  a  signal 
sorting  parameter  by  locating  a  threat  by  passive 
triangulation  using  two  or  more  HPCM  aircraft. 
This  aircraft  must  share  the  threat  data  from  pulse 
descriptor  words  (PDW)  that  are  formed  via  data 
telemetry.  Therefore,  the  aircraft  must  be  on  the 
same  master  system  clock  to  insure  that  the 
frequency  and  time  of  arrival  of  signals  had  their 
origin  at  the  same  threat.  All  of  these  features 
pose  signals  processing  challenges  for  the  system 
designer. 

HPCM  Recommended  Approach  for 
RASSP  Upgrade 

The  recommended  approach  for  RASSP 
methodology  implementation  would  be  to  have  a 
number  of  functional  system  modules  available. 
The  system  engineer  would  logically  arrange  the 
modules  at  a  computer  terminal.  Ilie  computer 
would  assemble  the  modules  and  assess  system 
performance  for  the  requested  result  (sensitivity, 
for  example).  The  system  output  would  be 
compared  to  the  performance  goals  outlined 
above.  Then,  the  engineer  would  work 
interactively  at  the  computer  terminal  to  either 
improve  system  performance  or  to  do 
cost/performance  tradeoff  studies.  The  end 
system  would  be  the  result  of  the  interactive 
design.  That  is,  RASSP  is  viewed  as  a  design 
aid. 

HPCM  RASSP  Use 

RASSP  would  initially  only  be  used  by  the 
senior  system  engineers  because  the  problems  are 
so  large  and  interrelated  that  they  are  almost 
intractable.  Interactive  computer  aided  system 
design  is  virtually  the  only  way  to  efficiently 
attract  the  system  design  and  cost  control 
problem.  Later,  as  the  merit  of  the  design 


approach  becomes  obvious  to  both  management 
and  more  junior  engineers,  its  use  will  be  both 
encouraged  and  desirable.  This  combination  will 
cause  its  growth  to  be  exponential,  not  unlike  our 
experience  with  the  use  of  PCs  in  the  workplace 

One  of  the  primary  features  of  RASSP  as 
conceived  for  this  program  is  that  it  is  used  as  an 
interactive  system  design  tool.  Any  detraction 
from  this  usage  could  be  a  deterrent  to  its  use. 
For  example,  if  RASSP  could  only  be  done  as  a 
batch  process  on  a  mainframe  computer  it  would 
lose  its  interactive  feature.  Other  contractual 
features  could  be  deterrents  to  the  interactive 
design.  For  example,  forcing  rigorous  system 
configuration  management  constraints  or 
extensive  design  reviews  before  system  changes 
can  be  implemented. 

Target  RASSP  System  -  ESM  Combat 

System 

Application: 

Advanced  Submarine  Tactical 

ESM  Combat  System 

System  (ASTECS)  ASARG,  ADKEM 

SYSTEMS  POINT  OF  CONTACT: 

James  Kolanek  (Raytheon) 

PROGRAM  MANATER: 

Jennifer  Horinek  (Raytheon) 

CONTRACTOR  SYSTEM 

Engineer  Behshad  Baseghi  (Digital  Rcvr) 
Jim  Kolanek  (ASTECS) 

System  Characteristics  Making  RASSP 
Use  Desirable 

The  receiver  unit  is  a  state-of-the-art  DSP  for  use 
in  ESM  in  different  threat  environments.  The 
trade-offs  between  sensitivity,  dynamic  range, 
pulse  width,  throughput,  etc  for  different 
applications  requires  hardware  modifications 
with  optimized  size  and  cost.  Below  are 
recommended  approaches  for  RASSP 
methodology  implementation  in  these  systems 
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and  how  to  assess  progress. 

•  Improvements  in  handling  denser 
environments,  resolution  and  effectiveness 
can  quickly  be  assessed  using  RASSP. 

•  Power  dissipation,  cost,  I/O  designs, 
manufacturing  yield  are  effective  elements  for 
any  system  designer  and  PMO  to  use  on 
quick  turn  around  hardware  (i.e.,  model  year 
hardware)  for  eventual  deployment  system. 
Same  as  that  presented  in  attached  HPCM 
memo  for  RASSP 


Target  RASSP  System  --  Low  Cost  EW 
Receiver 

Contact: 

Ron  Fairfield  AF-LNXA 
Raytheon  -  Henry  Leon 

Very  Compact/Low  cost  EW  system 

•  Receiver  Processor 

•  Resource  Management 

•  Technique  generation 

Large  real-time  digital  processing  component  of 
system  design  will  benefit  greatly  from  the  ability 
to  rapidly  prototype  alternate  approaches  to  find 
optimal  cosi/performance  solutions. 


3.11.5.4  Missile  Systems  Division  Candidates 


SYSTEM 

CANDIDATES 

- PLANNING - 

CONSIDERATIONS 

- FklNTlPLE - 

BENCHMARKS 

M3VANtll3  klNETit' 

ENERGY  MISSILE 
(ADKEM) 

LOOP  " 

(HIL)  1993 

*  ENHANCED  SIGNAL 
PROCESSOR  1995/6 

•  RASSP  MODEL  IN  1994 

'  RASSP  DEMO  IN  1995/6  HIL 

•  EXTREMELY  LOW 

T  ATFNIPY 

•  VOLUME,  POWER  AND 
COST 

•  GUIDANCE  ALGORITHMS 

•  AIM  POINT  SELECTION 
ALGORITHMS 

JOINT  direct 

ATTACK  MUNITIONS 
(JDAM) 

•  EXTREMELY  LOW  COST 
»  VOLUME  AND  POWER 

•  SAR  MAPPING 

•  OBJECT  RECOGNITION 
ALGORITHMS 

ADVANCED  LAND 

COMBAT  VEHICLE 

TECHNOLOGY 

(ALCVT) 

•  PHASE  II 1992-1194 

•  PHASE  in  1995-1997/87 

•  RASSP  MODEL  BASED  ON 
1994  TEST  RESULTS 

•  RASSP  DEMO  BY  TEST  BED 
INSERTION  IN  1995/6 

•  VOLUME,  POWER,  COST 

•  AUTOMATED  HIGH 
PROBABILITY  OF  TARGET 
ACQUISITION 

•  SENSOR  FUSION 
ALGORITHMS 

•  AIR  ALGORITHMS 

TABLE  3,11-15,  MSD'S  PRIMARY  RASSP  INSERTION  TARGETS 
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- SYSTEM - 

CANDIDATES 

CONTACTS 

CHARACTERISTICS 

ADVANCED  KINETIC 

ENERGY  MISSILE 
(ADKEM) 

TIMOTHY  CAREY - 
RAYTHEON 

MIKE  SCHEXNAYER  -  U.S. 
ARMY, 

MICOMLAB 

•  ANTI-TANK,  ANTI-AIR 

HIT  TO  KILL 

•  ATR,  RECOGNITION,  AIM 
POINT  SELECTION 

•  NEXT  GENERATION 
SIGNAL  PROCESSING  - 
GROWTH  WITH  THREAT 
ESCALATION 

JOINT  DIRECT 

ATTACK  MUNITIONS 
(JDAM) 

STEPHEN  MONAGHAN  - 
RAYTHEON 

TERRY  UTTLE  -  AIR  FORCE 
AFATTVAG 

•  AIR  TO  GROUND, 
PRECISION  TERMINAL 
GUIDELINES 

•  ATR,  SAR  IMAGING 

•  LOW  UNIT  COST 

•  ACCURACY  DRIVEN 

NEXT  GENERATION 
SIGNAL  PROCESSING 

ADVANCED  LAND 

COMBAT  VEHICLE 
TECHNOLOGY  (ALCVT) 

DR.  GREGORY  OSCHE  - 
RAYTHEON 

LTC.  THOMAS  QUINN  - 
DARPA/LSO 

•  INTEGRATED  LASER  AND 
MMW  RADAR  (ILAR) 

•  ATR,  HR  CONTROL, 
NON-COOPERATIVE  IFF 

•  FUTURE  TANK  DEFENSE 
TECHNOLOGY 
DEMANDING  NEXT 
GENERATION  SIGNAL 
PROCESSING 

TABLE  3.11-16,  USD’S  CONTACTS  FOR  RASSP  INSERTION  TARGETS 


I 

I 

I 
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After  review  of  all  Target  Systems,  it  was 
determined  that  the  Automatic  Target  Recognition 
application  was  the  most  suitable  for  use  as  a 
benchmark  model  throughout  the  development 
phase  of  RASSP.  Initially  a  simple 


model  in  behavioral  VHDL  could  be  established 
for  a  multi-application  processor.  Later  specific 
insertion  opportunities  could  be  marketed  for 
specific  configurations  of  this  model.  Final 
RASSP  system  could  be  exercised  for  critical 
Target  applications  as  appropriate  at  that  time. 
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